مدیریت حمل و نقل برای سال ها بیش از هر چیز به تجربه مدیر، شناخت رانندگان، حافظه کارکنان و مجموعه ای از فرم ها، تماس ها و اسناد وابسته بوده است. بسیاری از تصمیم ها نیز بر اساس همان چیزی گرفته می شدند که افراد از عملیات قبلی به خاطر داشتند: این مسیر معمولا چقدر زمان می برد، این راننده در کدام محدوده بهتر عمل می کند، برای یک نوع بار چه قیمتی منطقی است یا کدام مشتری سابقه بیشتری دارد.
اما با افزایش تعداد سفارش ها، رانندگان، مسیرها، تماس ها و تراکنش های مالی، اتکا به حافظه افراد به تنهایی نمی تواند تصویر کاملی از عملیات ایجاد کند.
اینجاست که ساختار یک نرم افزار عملیاتی اهمیت پیدا می کند.
ساختار مدیربار را نمی توان فقط با قابلیت هایی مانند ثبت سفارش، مدیریت راننده یا صدور اسناد حمل توضیح داد. این سامانه بخش های مختلف عملیات حمل و نقل را در یک زنجیره اطلاعاتی به یکدیگر متصل می کند؛ از تماس اولیه مشتری و محاسبه هزینه تا اجرای ماموریت، امور مالی و تحلیل داده.
جزئیات امکانات، بخش ها و نسخه های محصول در صفحه نرم افزار مدیریت بار مدیربار معرفی شده است. در این مقاله تمرکز بر فهرست امکانات نیست؛ بلکه بررسی می کنیم داده های تولید شده در بخش های مختلف نرم افزار چگونه به یکدیگر متصل می شوند و این ساختار چه نقشی در تحلیل و تصمیم گیری عملیاتی دارد.
به بیان ساده، موضوع این مقاله خود «امکانات نرم افزار» نیست، بلکه معماری اطلاعاتی پشت عملیات است.
ساختار نرم افزار مدیربار بر چه مبنایی شکل گرفته است؟
اگر یک عملیات حمل و نقل را از ابتدا تا انتها دنبال کنیم، با مجموعه ای از اتفاق های به ظاهر جدا از هم روبرو می شویم:
مشتری تماس می گیرد، اطلاعات درخواست ثبت می شود، مبدا و مقصد مشخص می شوند، نوع بار بررسی می شود، وسیله نقلیه انتخاب می شود، راننده یا نیروی انسانی تخصیص پیدا می کند، قیمت محاسبه می شود، عملیات اجرا می شود، زمان انجام کار ثبت می شود و در نهایت اطلاعات مالی و تسویه شکل می گیرد.
در یک سیستم پراکنده ممکن است هر کدام از این مراحل در یک دفتر، فایل یا نرم افزار مستقل ثبت شوند.
اما ارزش اصلی یک ساختار یکپارچه زمانی ایجاد می شود که این اطلاعات به عنوان اجزای یک عملیات واحد شناخته شوند.
در نسخه مورد بررسی مدیربار، بیش از ۲۰۰ فرم و بخش عملیاتی، ده ها موجودیت اطلاعاتی و صدها فرایند مرتبط با پایگاه داده وجود دارد. اهمیت این حجم از اطلاعات در تعداد فرم ها نیست؛ بلکه در ارتباطی است که میان داده های مختلف شکل می گیرد.
برای مثال یک سفارش صرفا یک ردیف ثبت شده نیست. می تواند به مشتری، آدرس، مسیر، راننده، وسیله نقلیه، نیروی انسانی، زمان، تعرفه، هزینه و اطلاعات مالی مرتبط باشد.
همین ارتباط است که داده خام را به داده قابل تحلیل تبدیل می کند.
از تماس مشتری تا پایان عملیات؛ شکل گیری یک زنجیره داده
یکی از مهم ترین ویژگی های یک سیستم اطلاعات عملیاتی این است که جریان داده را از همان نقطه آغاز درخواست دنبال کند.
در بسیاری از شرکت های حمل و نقل، اولین نقطه تماس مشتری با مجموعه، تماس تلفنی است. اگر این تماس تنها یک مکالمه باقی بماند، بخش مهمی از اطلاعات بازار از بین می رود.
اما وقتی تماس به یک مشتری، سفارش یا درخواست مشخص متصل شود، زنجیره داده از همان لحظه آغاز می شود.
برای مثال می توان چنین مسیری را در نظر گرفت:
تماس مشتری ← ثبت درخواست ← تعیین مبدا و مقصد ← مشخصات بار ← انتخاب خودرو ← انتخاب راننده ← تعیین نیروی انسانی ← محاسبه هزینه ← اجرای عملیات ← ثبت زمان ← ثبت وضعیت مالی ← تسویه
هر مرحله اطلاعات جدیدی به همان عملیات اضافه می کند.
به این ترتیب موضوع اصلی فقط «ثبت سفارش» نیست. موضوع، ساختن یک پرونده اطلاعاتی برای هر ماموریت حمل و نقل است.
هرچه این پرونده کامل تر باشد، تحلیل های بعدی نیز قابل اتکاتر خواهند بود.
تبدیل تجربه افراد به حافظه سازمانی
یکی از مشکلات رایج در کسب و کارهای خدماتی این است که بخش زیادی از دانش عملیاتی در ذهن افراد باقی می ماند.
ممکن است یک مدیر با سال ها تجربه بداند:
- کدام مسیر معمولا زمان بیشتری می گیرد؛
- کدام محدوده در ساعات خاص شلوغ تر است؛
- برای یک نوع بار چه وسیله ای مناسب تر است؛
- یک راننده معمولا در چه مناطقی فعالیت می کند؛
- چه مشتریانی سابقه همکاری بیشتری دارند؛
- نرخ های گذشته برای یک مسیر در چه محدوده ای بوده اند.
این دانش ارزشمند است، اما اگر تنها در حافظه افراد باقی بماند، یک دارایی سازمانی محسوب نمی شود.
با ثبت مستمر عملیات، بخشی از این تجربه به داده تبدیل می شود.
سوابق حمل، زمان انجام سرویس، نرخ های قبلی، مسیرها، رانندگان، تماس ها و سفارش ها به مرور یک حافظه عملیاتی برای مجموعه ایجاد می کنند.
تفاوت مهم این دو مدل در این است که حافظه انسانی وابسته به فرد است، اما حافظه داده محور می تواند در سطح سازمان باقی بماند و توسط افراد مختلف مورد استفاده قرار گیرد.
محاسبه به جای حدس
یکی از بخش هایی که اهمیت ساختار داده را به خوبی نشان می دهد، محاسبه هزینه خدمات است.
هزینه یک عملیات حمل و نقل همیشه از یک عدد ثابت تشکیل نمی شود. متغیرهای متعددی می توانند روی آن اثر بگذارند.
برای نمونه در یک عملیات شهری ممکن است عواملی مانند موارد زیر مطرح باشند:
- نوع وسیله نقلیه
- محدوده مبدا و مقصد
- تعداد نیروی انسانی
- مدت پایه سرویس
- مدت واقعی عملیات
- طبقات مبدا و مقصد
- وجود یا نبود آسانسور
- اقلام سنگین
- تجهیزات مورد نیاز
- خدمات جانبی
وقتی این عوامل به صورت ساخت یافته ثبت شوند، محاسبه می تواند از حالت تخمینی و کاملا وابسته به فرد فاصله بگیرد.
همین منطق درباره هزینه نیروی انسانی یا سایر اجزای عملیات نیز قابل استفاده است.
در حمل بین شهری نیز هزینه نهایی می تواند از اجزای مختلفی مانند هزینه پایه حمل، عوارض، کمیسیون و سایر هزینه های مرتبط تشکیل شود.
اهمیت این ساختار صرفا در سریع تر شدن محاسبه نیست.
موضوع مهم تر، ایجاد یک منطق قابل تکرار است.
اگر دو کارشناس با اطلاعات ورودی یکسان به نتایج کاملا متفاوت برسند، تصمیم گیری به فرد وابسته است. اما وقتی متغیرها و قواعد مشخص باشند، امکان استانداردسازی بیشتر می شود.
داده های تاریخی چگونه به تصمیم درباره کرایه کمک می کنند؟
یکی از ارزشمندترین دارایی های یک سیستم عملیاتی، تاریخچه آن است.
فرض کنیم برای یک مبدا، مقصد و نوع وسیله مشخص، ده ها عملیات در ماه های گذشته ثبت شده باشد.
در این حالت سیستم فقط مجموعه ای از نرخ های قدیمی در اختیار ندارد. بلکه یک سابقه عملیاتی ایجاد شده است که می تواند برای مقایسه و تصمیم گیری استفاده شود.
برای مثال می توان بررسی کرد:
- آخرین نرخ ثبت شده چه مقدار بوده است؛
- نرخ های یک مسیر در طول زمان چگونه تغییر کرده اند؛
- میانگین قیمت عملیات مشابه چقدر بوده است؛
- چه نوع وسیله ای بیشتر در این مسیر استفاده شده است؛
- تعداد عملیات در یک بازه زمانی چگونه تغییر کرده است.
البته نرخ تاریخی لزوما به معنی نرخ مناسب امروز نیست.
شرایط بازار، هزینه ها، فصل، ظرفیت ناوگان و عوامل دیگر می توانند تغییر کنند.
بنابراین داده تاریخی بهتر است به عنوان یک ورودی برای تصمیم گیری دیده شود، نه یک پاسخ قطعی.
هرچه تاریخچه داده طولانی تر و کیفیت ثبت اطلاعات بهتر باشد، امکان مقایسه نیز افزایش پیدا می کند.
مشتری در این ساختار فقط یک شماره تماس نیست
در یک سیستم ساده، مشتری ممکن است فقط یک نام و شماره تلفن باشد.
اما در یک ساختار داده محور، مشتری می تواند به مجموعه ای از اطلاعات مرتبط شود:
- اطلاعات تماس
- آدرس ها
- گیرندگان
- سفارش های قبلی
- مسیرهای پرتکرار
- یادداشت ها
- شکایت ها
- تماس های قبلی
- سابقه خدمات
- فعالیت یا عدم فعالیت در دوره های مختلف
وقتی این داده ها در کنار یکدیگر قرار بگیرند، مفهوم مشتری از یک رکورد ساده فراتر می رود.
برای مثال ممکن است مشخص شود یک مشتری در یک دوره مشخص سفارش های پرتکراری داشته اما در ماه های اخیر فعالیتش کاهش یافته است.
یا مشتری دیگری در مسیرهای مشخصی به صورت دوره ای درخواست حمل ثبت می کند.
این اطلاعات می توانند پایه تحلیل رفتار مشتری باشند.
در چنین شرایطی سیستم دیگر فقط پاسخ نمی دهد «این مشتری چه کسی است؟»
بلکه به تدریج می تواند به پرسش هایی مانند این نزدیک شود:
این مشتری چگونه از خدمات استفاده می کند؟
آخرین فعالیت او چه زمانی بوده است؟
چه نوع سرویس هایی برای او تکرار شده اند؟
آیا الگوی سفارش او تغییر کرده است؟
راننده به عنوان یک موجودیت قابل ارزیابی
در یک سیستم داده محور، راننده نیز تنها یک نام در فهرست رانندگان نیست.
هر راننده می تواند یک سابقه عملیاتی داشته باشد.
اطلاعات هویتی، مدارک، وسیله نقلیه، ماموریت ها، رزروها، وضعیت مالی و سوابق عملکرد می توانند به یکدیگر مرتبط شوند.
این ساختار امکان تحلیل هایی مانند موارد زیر را فراهم می کند:
- تعداد ماموریت های انجام شده
- محدوده های فعالیت
- سابقه تاخیر
- تعداد کنسلی
- عملکرد در دوره های زمانی مختلف
- وضعیت مالی و تسویه
- نوع ماموریت های انجام شده
اگر داده کافی وجود داشته باشد، به مرور می توان از یک فهرست ساده رانندگان به سمت پروفایل عملیاتی راننده حرکت کرد.
در این حالت انتخاب راننده فقط بر اساس شناخت شخصی مدیر انجام نمی شود و سابقه ثبت شده نیز می تواند بخشی از تصمیم باشد.
زمان عملیات چگونه به یک داده اقتصادی تبدیل می شود؟
زمان یکی از مهم ترین متغیرهای حمل و نقل است، اما در بسیاری از مجموعه ها به شکل ساخت یافته ثبت نمی شود.
اگر زمان شروع و پایان عملیات، مسیر، محدوده، نوع خدمت و سایر متغیرهای مرتبط ثبت شوند، زمان از یک مشاهده ساده به یک داده قابل تحلیل تبدیل می شود.
برای نمونه می توان زمان عملیات مشابه را بر اساس محله، روز، ماه، طبقه یا نوع سرویس مقایسه کرد.
از نظر آماری نیز می توان شاخص هایی مانند موارد زیر را بررسی کرد:
- حداقل زمان
- حداکثر زمان
- میانگین
- میانه
- نما
- انحراف معیار
فرض کنیم میانگین زمان یک نوع سرویس سه ساعت باشد، اما انحراف معیار بسیار بالا باشد.
در این حالت میانگین به تنهایی تصویر دقیقی از عملیات ارائه نمی دهد و باید بررسی شود چرا بعضی ماموریت ها بسیار کوتاه و برخی بسیار طولانی هستند.
ممکن است علت به منطقه، ترافیک، طبقات، نوع بار، نیروی انسانی یا عوامل دیگری مرتبط باشد.
از اینجا زمان به یک داده اقتصادی تبدیل می شود؛ زیرا مدت عملیات می تواند روی ظرفیت روزانه، هزینه نیروی انسانی، استفاده از خودرو و تعداد سرویس قابل انجام اثر بگذارد.
داده های سفارش چگونه تصویری از تقاضا می سازند؟
برای شناخت تقاضا همیشه به یک نقشه پیچیده جغرافیایی نیاز نیست.
گاهی همین داده های سفارش می توانند تصویری اولیه از توزیع تقاضا ایجاد کنند.
برای مثال می توان بررسی کرد:
- کدام محدوده ها سفارش بیشتری دارند؛
- چه مسیرهایی بیشتر تکرار می شوند؛
- چه ساعاتی تماس یا سفارش افزایش پیدا می کند؛
- کدام روزهای هفته پرترافیک تر هستند؛
- چه نوع وسیله ای در یک محدوده بیشتر درخواست می شود.
اگر این داده ها با زمان و نوع سرویس ترکیب شوند، اطلاعات کاربردی تری به دست می آید.
برای مثال ممکن است مشخص شود در یک محدوده خاص، عصرهای پایان هفته درخواست خودرو بیشتر می شود.
این شناخت می تواند در تخصیص منابع، برنامه ریزی رانندگان و پاسخگویی مرکز تماس موثر باشد.
در چنین حالتی سفارش ها فقط سوابق گذشته نیستند. آن ها به تدریج تصویری از الگوی تقاضا می سازند.
مرکز تماس؛ یک حسگر برای رفتار بازار
مرکز تماس معمولا به عنوان واحد پاسخگویی دیده می شود، اما از دید داده، تماس ها می توانند یکی از مهم ترین منابع شناخت بازار باشند.
هر تماس ممکن است نشان دهنده یک نیاز، درخواست، سوال، شکایت یا تقاضای بالقوه باشد.
اگر تماس ها دسته بندی و به مشتری یا سفارش مرتبط شوند، می توان شاخص های مختلفی را بررسی کرد.
برای مثال:
- تعداد تماس ها در روز
- ساعات اوج تماس
- روزهای شلوغ
- نوع درخواست های پرتکرار
- تعداد تماس هایی که به سفارش تبدیل شده اند
- تماس های مشتریان قدیمی
- تماس هایی که بدون ثبت سفارش پایان یافته اند
این اطلاعات حتی می توانند زودتر از سفارش های نهایی، تغییر در تقاضا را نشان دهند.
برای نمونه افزایش تماس درباره یک نوع خدمت ممکن است پیش از افزایش واقعی سفارش ها دیده شود.
به همین دلیل مرکز تماس را می توان نه فقط یک کانال ارتباطی، بلکه یکی از منابع داده بازار دانست.
اتصال عملیات حمل و نقل به اطلاعات مالی
یک عملیات حمل و نقل فقط زمانی قابل تحلیل اقتصادی است که اطلاعات عملیاتی آن به اطلاعات مالی مرتبط باشند.
در یک ماموریت ممکن است اجزای مختلفی وجود داشته باشند:
کرایه، هزینه نیروی انسانی، کمیسیون، تخفیف، خدمات جانبی، دریافت ها، پرداخت ها، اسناد مالی و وضعیت تسویه.
اگر این اطلاعات جدا از عملیات اصلی نگهداری شوند، پاسخ به برخی سوال های مدیریتی دشوار می شود.
مثلا:
یک سرویس مشخص چه درآمدی ایجاد کرده است؟
چه هزینه هایی به آن مرتبط بوده اند؟
وضعیت تسویه آن چیست؟
چه میزان از مبلغ هنوز دریافت نشده است؟
یک مشتری یا راننده چه وضعیت مالی دارد؟
وقتی عملیات و مالی به یکدیگر متصل شوند، به تدریج می توان به سمت تحلیل اقتصاد هر عملیات حرکت کرد.
این موضوع برای مدیر اهمیت زیادی دارد، زیرا تعداد بالای سرویس لزوما به معنای عملکرد مالی مناسب نیست.
ممکن است یک نوع عملیات تعداد زیادی سفارش داشته باشد اما هزینه اجرای آن نیز بالا باشد.
بدون اتصال داده مالی به داده عملیاتی، این تفاوت به سادگی دیده نمی شود.
چرا ارزش داده با افزایش تاریخچه بیشتر می شود؟
یکی از تفاوت های مهم نرم افزارهای عملیاتی با ابزارهای ساده ثبت اطلاعات این است که ارزش آن ها می تواند با انباشته شدن تاریخچه افزایش پیدا کند.
در روزهای ابتدایی، سیستم بیشتر برای ثبت و مدیریت عملیات استفاده می شود.
اما پس از گذشت زمان، داده های قبلی به یک منبع جدید تبدیل می شوند.
هر عملیات می تواند اطلاعاتی درباره موارد زیر ایجاد کند:
- قیمت
- مدت زمان
- مسیر
- نوع تقاضا
- راننده
- مشتری
- هزینه
- نحوه اجرا
- نتیجه عملیات
اگر این اطلاعات به صورت منظم ثبت شوند، مجموعه پس از مدتی نه فقط یک نرم افزار عملیاتی، بلکه یک پایگاه دانش درباره کسب و کار خود در اختیار دارد.
البته حجم داده به تنهایی کافی نیست.
اگر اطلاعات ناقص، ناسازگار یا اشتباه ثبت شوند، افزایش تعداد رکوردها لزوما ارزش تحلیلی بیشتری ایجاد نمی کند.
کیفیت داده، تعریف درست متغیرها، یکسان بودن روش ثبت و کنترل خطاها اهمیت زیادی دارند.
بنابراین ارزش تاریخچه زمانی افزایش پیدا می کند که داده قابل اعتماد باشد.
آیا ساختار مدیربار به مفهوم Digital Twin نزدیک می شود؟
اصطلاح Digital Twin یا دوقلوی دیجیتال معمولا به بازنمایی دیجیتال یک سیستم واقعی گفته می شود که وضعیت اجزا و تغییرات آن را در فضای دیجیتال منعکس می کند.
استفاده از این اصطلاح برای هر نرم افزار مدیریتی دقیق نیست.
با این حال در ساختاری که اطلاعات مشتری، راننده، وسیله نقلیه، مسیر، نیروی انسانی، تماس، زمان، قیمت، اسناد مالی و نتیجه عملیات به یکدیگر متصل می شوند، می توان نوعی حرکت به سمت بازنمایی دیجیتال عملیات را مشاهده کرد.
در فضای واقعی یک شرکت حمل و نقل، رانندگان حرکت می کنند، مشتریان درخواست ثبت می کنند، بار جابه جا می شود، هزینه ایجاد می شود و عملیات در طول زمان تغییر می کند.
در فضای نرم افزار نیز بخشی از همین اتفاق ها به رکوردهای اطلاعاتی تبدیل می شوند.
هرچه ارتباط میان دنیای واقعی و داده های ثبت شده دقیق تر باشد، تصویر دیجیتال عملیات نیز کامل تر می شود.
با این حال بهتر است مدیربار را بدون بررسی مولفه های فنی لازم، یک Digital Twin کامل ننامیم.
توصیف دقیق تر این است که ساختار آن می تواند به سمت «بازنمایی دیجیتال عملیات حمل و نقل» حرکت کند.
ساختار داده مدیربار چه ارتباطی با هوش مصنوعی دارد؟
هوش مصنوعی بدون داده قابل اعتماد ارزش محدودی دارد.
برای ساخت مدل هایی که بتوانند درباره قیمت، تقاضا، زمان یا رفتار مشتری پیش بینی انجام دهند، ابتدا باید داده تاریخی کافی وجود داشته باشد.
به همین دلیل مرحله مهم قبل از AI، ساخت یک زیرساخت داده مناسب است.
اگر اطلاعاتی مانند موارد زیر در طول زمان ثبت شوند:
- تعداد سفارش ها
- زمان عملیات
- مبدا و مقصد
- نوع وسیله
- نرخ
- وضعیت راننده
- سابقه مشتری
- نتیجه عملیات
- کنسلی
- تاخیر
در آینده می توان بررسی کرد آیا داده برای ساخت مدل های تحلیلی یا پیش بینی مناسب است یا خیر.
برای مثال یک مدل می تواند تلاش کند به سوال هایی از این نوع پاسخ دهد:
در چه ساعاتی احتمال افزایش تقاضا بیشتر است؟
زمان تقریبی یک عملیات مشابه چقدر است؟
کدام عوامل بیشترین ارتباط را با تاخیر دارند؟
کدام مشتریان احتمال کمتری برای سفارش مجدد دارند؟
در یک مسیر مشخص چه بازه قیمتی در گذشته مشاهده شده است؟
اما رسیدن به این مرحله فقط به داشتن تعداد زیادی رکورد وابسته نیست.
کیفیت داده، تعداد نمونه ها، انتخاب متغیرها، شرایط بازار، روش آموزش مدل و ارزیابی خروجی همگی اهمیت دارند.
بنابراین مزیت اصلی یک ساختار داده محور این نیست که برچسب «هوش مصنوعی» روی نرم افزار قرار بگیرد.
مزیت واقعی این است که اگر روزی استفاده از مدل های پیش بینی توجیه داشته باشد، داده واقعی عملیات برای ساخت آن وجود داشته باشد.
مدیربار را چگونه باید از منظر ساختار اطلاعاتی دید؟
اگر فقط ظاهر یک نرم افزار بررسی شود، ممکن است مجموعه ای از فرم ها، جداول و گزارش ها دیده شود.
اما از منظر معماری اطلاعات، موضوع متفاوت است.
هر فرم در واقع نقطه ورود یا نمایش بخشی از یک شبکه داده است.
مشتری به سفارش متصل است.
سفارش به مسیر متصل است.
مسیر می تواند به قیمت و زمان مرتبط باشد.
عملیات به راننده، خودرو و نیروی انسانی متصل می شود.
نتیجه عملیات می تواند به اطلاعات مالی و سابقه مشتری اضافه شود.
به همین دلیل ساختار مدیربار را بهتر است نه صرفا به عنوان مجموعه ای از فرم های مدیریتی، بلکه به عنوان یک سیستم اطلاعات عملیاتی بررسی کرد.
سیستمی که هدف آن ثبت جداگانه اتفاق ها نیست؛ بلکه ایجاد ارتباط میان اتفاق های مختلف یک کسب و کار حمل و نقل است.
از گزارش گیری تا تحلیل علت
اولین سطح استفاده از داده معمولا گزارش گیری است.
برای مثال:
این ماه چند سرویس انجام شده است؟
چند راننده فعال بوده اند؟
مجموع تماس ها چقدر بوده است؟
چه مقدار درآمد ثبت شده است؟
این سطح به مدیر می گوید «چه اتفاقی افتاده است؟»
اما مرحله بعدی، تحلیل علت است.
در این مرحله سوال ها تغییر می کنند:
چرا تعداد سفارش ها کاهش پیدا کرده است؟
به چه دلیل مدت عملیات در یک منطقه بیشتر است؟
دلیل اینکه تعداد کنسلی در یک بازه افزایش یافته است چیست؟
چرا یک گروه از مشتریان کمتر سفارش می دهند؟
برای پاسخ به این سوال ها باید چند نوع داده با یکدیگر ترکیب شوند.
برای مثال افزایش زمان عملیات ممکن است فقط با نگاه به گزارش زمان قابل توضیح نباشد.
شاید لازم باشد منطقه، روز هفته، نوع بار، راننده، تعداد کارگر و طبقات نیز بررسی شوند.
ارزش معماری داده دقیقا در چنین شرایطی مشخص می شود.
مرحله بعد؛ پیش بینی آنچه ممکن است اتفاق بیفتد
پس از ایجاد تاریخچه کافی، سطح بعدی تحلیل می تواند به پیش بینی مربوط شود.
در این مرحله سوال اصلی دیگر «چه شد؟» یا «چرا شد؟» نیست.
سوال این است:
«احتمالا چه خواهد شد؟»
برای مثال:
تقاضا در ساعات آینده چگونه خواهد بود؟
یک عملیات مشابه احتمالا چقدر طول می کشد؟
در یک بازه زمانی مشخص چه تعداد راننده نیاز است؟
احتمال کنسلی یک سفارش چقدر است؟
البته پیش بینی همیشه با عدم قطعیت همراه است و نباید به عنوان نتیجه قطعی در نظر گرفته شود.
اما حتی یک برآورد مبتنی بر داده می تواند در برخی تصمیم ها مفیدتر از حدس بدون سابقه باشد.
از پیش بینی تا پیشنهاد اقدام
مرحله پیشرفته تر زمانی است که سیستم فقط وضعیت را گزارش یا پیش بینی نکند، بلکه گزینه های عملیاتی را نیز پیشنهاد دهد.
برای مثال:
در یک بازه زمانی تقاضا در حال افزایش است.
تعداد رانندگان آماده کمتر از سطح معمول است.
زمان متوسط عملیات در یک محدوده افزایش یافته است.
بر اساس این داده ها ممکن است سیستم در آینده پیشنهاد دهد ظرفیت بیشتری برای آن محدوده در نظر گرفته شود.
یا اگر مشتری خاصی برای مدت طولانی غیرفعال شده باشد، این وضعیت می تواند به عنوان سیگنال پیگیری ثبت شود.
این نوع سیستم ها معمولا در چهار سطح توصیف می شوند:
Descriptive: چه اتفاقی افتاد؟
Diagnostic: چرا اتفاق افتاد؟
Predictive: چه چیزی ممکن است اتفاق بیفتد؟
Prescriptive: چه اقدامی می تواند مناسب باشد؟
حرکت از سطح اول به سطوح بالاتر نیازمند داده، کیفیت ثبت، قواعد مناسب و مدل های تحلیلی قابل اعتماد است.
چرا معماری داده از تعداد قابلیت ها مهم تر است؟
در نگاه اول ممکن است تعداد امکانات یک نرم افزار معیار اصلی ارزیابی باشد.
اما از دید بلندمدت، نحوه ارتباط اطلاعات اهمیت بیشتری پیدا می کند.
فرض کنیم یک سیستم ده ها قابلیت داشته باشد، اما هر بخش اطلاعات خود را به صورت مستقل نگهداری کند.
در این حالت گزارش گیری میان بخش ها دشوار خواهد بود.
در مقابل، اگر داده ها حول موجودیت های مشخص و روابط روشن طراحی شده باشند، امکان تحلیل گسترده تری ایجاد می شود.
برای نمونه اگر مشتری، سفارش، راننده، زمان و هزینه به یک عملیات مشترک مرتبط باشند، می توان سوال هایی مطرح کرد که در سیستم های جزیره ای پاسخ دادن به آن ها دشوار است.
مثلا:
مشتریان پرتکرار بیشتر چه نوع سرویس هایی درخواست می کنند؟
کدام مسیرها علاوه بر سفارش بالا، زمان اجرای بیشتری دارند؟
کدام رانندگان در محدوده های خاص سابقه بیشتری دارند؟
چه نوع عملیات هایی بیشترین نوسان زمانی را دارند؟
کدام عوامل با افزایش هزینه همزمان هستند؟
بنابراین مهم ترین بخش یک ساختار داده محور فقط فرم ورود اطلاعات نیست؛ رابطه میان اطلاعات است.
داده عملیاتی چگونه به دارایی سازمانی تبدیل می شود؟
یک سفارش پس از پایان حمل ممکن است در ظاهر تمام شده باشد.
اما اطلاعات آن همچنان می تواند ارزش داشته باشد.
آن عملیات مشخص کرده است:
چه کسی درخواست داده است؟
چه خدمتی خواسته است؟
مبدا و مقصد کجا بوده اند؟
چه راننده ای عملیات را انجام داده است؟
چه مدت طول کشیده است؟
هزینه چگونه محاسبه شده است؟
نتیجه عملیات چه بوده است؟
وقتی هزاران عملیات مشابه در کنار یکدیگر قرار گیرند، تصویری از رفتار واقعی کسب و کار ایجاد می شود.
این داده ها می توانند به مدیر کمک کنند تفاوت میان تصور و واقعیت عملیات را بهتر ببیند.
ممکن است تصور شود یک محدوده مهم ترین بازار شرکت است، اما داده سفارش ها منطقه دیگری را نشان دهد.
ممکن است تصور شود یک نوع سرویس زمان ثابتی دارد، اما تحلیل آماری نوسان بالایی را نشان دهد.
در چنین شرایطی داده فقط برای ثبت گذشته استفاده نشده است؛ بلکه به یک دارایی برای شناخت سازمان تبدیل شده است.
کیفیت تصمیم گیری به کیفیت ثبت اطلاعات وابسته است
هر سیستم تحلیلی یک محدودیت مهم دارد:
اگر داده ورودی اشتباه باشد، خروجی نیز قابل اعتماد نخواهد بود.
زمان عملیات به درستی ثبت نشود، تحلیل زمان دقت کافی ندارد.
نوع وسیله اشتباه انتخاب شود، مقایسه نرخ ها مخدوش می شود.
مشتریان تکراری با چند مشخصات متفاوت ثبت شوند، تحلیل رفتار مشتری دچار خطا می شود.
وضعیت سفارش به روز نشود، گزارش عملیات تصویر واقعی را نشان نمی دهد.
به همین دلیل توسعه یک سیستم داده محور فقط مسئله برنامه نویسی نیست.
فرایند ثبت اطلاعات، آموزش کاربران، تعریف استانداردها و کنترل کیفیت داده نیز بخشی از معماری عملیاتی هستند.
در واقع هرچه تصمیم های مهم تری بر اساس داده گرفته شوند، اهمیت کیفیت داده نیز افزایش پیدا می کند.
جمع بندی
بررسی ساختار نرم افزار مدیربار فقط با شمردن قابلیت ها و بخش های آن تصویر کاملی ارائه نمی دهد.
لایه مهم تر، ارتباط میان داده هایی است که در جریان واقعی عملیات ایجاد می شوند.
تماس مشتری، سفارش، آدرس، مسیر، راننده، وسیله نقلیه، نیروی انسانی، کرایه، زمان، اطلاعات مالی و نتیجه عملیات، زمانی ارزش بیشتری پیدا می کنند که به صورت جدا از یکدیگر نگهداری نشوند.
این ارتباط می تواند به مرور سه نوع ارزش ایجاد کند:
نخست، تبدیل تجربه افراد به حافظه سازمانی.
دوم، تبدیل عملیات روزمره به داده قابل اندازه گیری و تحلیل.
و سوم، ایجاد زیرساختی که در آینده بتوان بر اساس آن مدل های تحلیلی، پیش بینی و ابزارهای پشتیبان تصمیم ساخت.
در چنین نگاهی، نرم افزار دیگر فقط محل ثبت اتفاق هایی نیست که قبلا رخ داده اند.
هر عملیات جدید بخشی از تصویر بزرگ تری را کامل می کند؛ تصویری از مشتری، بازار، ناوگان، زمان، هزینه و عملکرد واقعی مجموعه.
ارزش نهایی این ساختار نیز زمانی مشخص می شود که داده ثبت شده بتواند به سوال های مدیریتی پاسخ دهد و کیفیت تصمیم گیری را بهبود دهد.