سازمان نقشه راه تحول دیجیتال دارد. چند پروژه تعریف شدهاند، فناوریهای جدید در حال بررسیاند و واحدهای مختلف نیز ابتکارهای خود را دنبال میکنند.
اما یک سؤال همچنان باقی است:
این برنامه دقیقاً چه زمانی به تغییری در عملیات روزمره سازمان تبدیل میشود؟
فاصله میان «برنامه تحول» و «تغییر عملیاتی» زمانی شکل میگیرد که یک ابتکار مدیریتی هنوز به فرایندی واقعی، مسئولیتهای مشخص، داده قابل استفاده و سامانهای که کارکنان با آن کار کنند تبدیل نشده است.
برای عبور از این فاصله، صرف تعریف پروژه یا خرید فناوری کافی نیست. هر ابتکار تحول باید آنقدر مشخص شود که بتوان آن را اجرا، اندازهگیری و براساس نتیجه اصلاح کرد.
مسئله تحول دیجیتال معمولاً کمبود فناوری نیست
فناوری بخش مهمی از تحول دیجیتال است، اما در اختیار داشتن فناوری با ایجاد تغییر عملیاتی یکسان نیست.
یک سازمان ممکن است ابزارهای جدیدی در اختیار داشته باشد، اما فرایندهای آن همچنان به روش گذشته اجرا شوند. ممکن است داده بیشتری تولید شود، اما تصمیمهای روزمره همچنان به اطلاعات پراکنده وابسته باشند. حتی ممکن است چند پروژه دیجیتال همزمان در جریان باشند، بدون اینکه به یک تغییر منسجم در عملیات منجر شوند.
فناوری زمانی ارزش عملی پیدا میکند که به یک مسئله واقعی متصل شود و شیوه انجام کار را بهصورت قابل استفاده تغییر دهد.
خرید ابزار با تغییر عملیاتی یکسان نیست
فرض کنید سازمان یک نرمافزار جدید خریداری کرده است.
اگر همان فعالیتهای قبلی، با همان مسئولیتهای مبهم و همان تبادل دستی اطلاعات فقط در محیطی جدید انجام شوند، بخش محدودی از مسئله حل شده است.
تغییر عملیاتی زمانی رخ میدهد که روشن باشد فناوری قرار است کدام بخش از کار را تغییر دهد: چه فعالیتی بازطراحی میشود، مسئولیتها چگونه تعریف میشوند، اطلاعات از کجا میآیند و چه نتیجهای باید قابل مشاهده باشد.
به همین دلیل، انتخاب ابزار باید بعد از روشنشدن مسئله قرار گیرد، نه بهجای تعریف مسئله.
پروژه فناوری با نتیجه کسبوکاری یکسان نیست
«سامانه تحویل شد» یک خروجی پروژه است.
اما مدیر تحول معمولاً سؤال دیگری دارد: آیا چیزی که برای کسبوکار مهم بود تغییر کرده است؟
ممکن است مسئله اصلی توقف طولانی در یک مرحله، نبود دید بر وضعیت پروندهها، ورود چندباره اطلاعات یا دشواری هماهنگی میان چند واحد باشد.
اگر نتیجه مورد انتظار از ابتدا مشخص نشده باشد، پایان پروژه فنی الزاماً به معنای تحقق هدف تحول نیست.
فناوری میتواند اجرای تغییر را ممکن کند، اما نتیجه همچنان به انتخاب درست مسئله، حمایت مدیریت، بازطراحی فرایند، کیفیت داده، مدیریت تغییر و مشارکت کاربران وابسته است.
سند تحول با سازوکار اجرایی یکسان نیست
نقشه راه مشخص میکند سازمان میخواهد به کجا برسد. اجرای عملیاتی باید نشان دهد این حرکت چگونه در فعالیتهای واقعی اتفاق میافتد.
برای مثال، عبارت «دیجیتالیکردن خدمات داخلی» جهت کلی را مشخص میکند، اما برای اجرا هنوز باید بدانیم:
کدام خدمت قرار است تغییر کند؟ مسئله فعلی چیست؟ مالک نتیجه کیست؟ چه واحدهایی درگیرند؟ کدام فرایند باید بازطراحی شود؟ چه سامانههایی باید با یکدیگر کار کنند؟ و موفقیت چگونه سنجیده خواهد شد؟
تا زمانی که این پرسشها پاسخ اولیه نداشته باشند، ابتکار تحول هنوز برای تبدیلشدن به یک سناریوی اجرایی آماده نیست.
فاصله برنامه تحول تا اجرا از کجا ایجاد میشود؟
معمولاً یک عامل واحد مسئول این فاصله نیست. چند ابهام کوچک میتوانند در کنار هم اجرای پروژه را دشوار کنند.
مسئله بیش از حد کلی تعریف شده است
«دیجیتالیشدن سازمان»، «بهبود تجربه کاربران» یا «هوشمندسازی عملیات» میتوانند جهتگیریهای مهمی باشند، اما هنوز واحد اجرایی مشخصی نیستند.
برای شروع باید بتوان مسئلهای را تعریف کرد که در عملیات قابل مشاهده باشد.
مثلاً بهجای «دیجیتالیسازی فرایندهای داخلی» میتوان روی فرایندی تمرکز کرد که امروز وضعیت آن برای واحدهای درگیر شفاف نیست یا اطلاعات آن میان چند سامانه و فعالیت دستی جابهجا میشود.
هرچه مسئله مشخصتر باشد، تعیین دامنه و نتیجه مورد انتظار نیز روشنتر خواهد شد.
مالک و دامنه اجرایی مشخص نیست
هر ابتکار باید مالک نتیجه داشته باشد.
اگر درباره مسیر آینده، اولویتها یا تغییرات لازم اختلاف ایجاد شود، باید معلوم باشد تصمیم نهایی از چه مسیری گرفته میشود.
دامنه نیز باید روشن باشد. یک ابتکار بدون مرز مشخص میتواند بهتدریج بخشهای بیشتری از سازمان را درگیر کند و به پروژهای تبدیل شود که نتیجه مرحله نخست آن بهسختی قابل ارزیابی است.
در عمل، هر ابتکار زمانی به اجرا نزدیکتر میشود که دامنه، مالک و شاخص موفقیت آن مشخص باشند.
فرایند آینده هنوز طراحی نشده است
گاهی فناوری انتخاب شده، اما روش مطلوب انجام کار پس از تغییر هنوز روشن نیست.
در این مرحله باید فرایند To-Be تعریف شود. To-Be یعنی وضعیت مطلوب فرایند بعد از تغییر.
لازم نیست مدل اولیه تمام جزئیات فنی را داشته باشد، اما باید روشن کند کار چگونه آغاز میشود، نقشهای اصلی چه کسانی هستند، تصمیمهای مهم در کجا گرفته میشوند و پایان مطلوب فرایند چیست.
قرارگرفتن فناوری روی فرایندی که هنوز درباره منطق آینده آن توافقی وجود ندارد، فقط ابهام کسبوکاری را به مرحله توسعه منتقل میکند.
برای جزئیات این مرحله، مقاله «آمادهسازی فرایند برای دیجیتالیسازی» مسیر کاملتری ارائه میکند.
داده و سامانههای درگیر مشخص نشدهاند
فرایندهای سازمانی معمولاً در یک سامانه بسته اجرا نمیشوند.
ممکن است بخشی از اطلاعات در یک سامانه تخصصی نگهداری شود، داده دیگری از یک سرویس دریافت شود و نتیجه فرایند نیز باید به سیستم دیگری منتقل شود.
بنابراین پیش از اجرا باید بدانیم چه دادهای لازم است، مالک آن کیست، منبع مرجع آن کدام سامانه است و کدام یکپارچهسازیها برای اجرای سناریو ضروریاند.
هدف، طراحی کامل معماری در اولین جلسه نیست. هدف این است که وابستگیهای اصلی تا زمان شروع توسعه پنهان نمانند.
معیار موفقیت از ابتدا تعریف نشده است
اگر موفقیت فقط با عبارت «سامانه راهاندازی شد» سنجیده شود، تشخیص اثر واقعی ابتکار دشوار خواهد بود.
برای یک پروژه ممکن است زمان چرخه مهم باشد؛ برای دیگری، تعداد برگشتها، زمان انتظار یا امکان مشاهده وضعیت فرایند اهمیت بیشتری داشته باشد.
شاخص مناسب به مسئله بستگی دارد.
اصل مهم این است که پیش از اجرا بدانیم چه تغییری قرار است قابل مشاهده باشد.
هر ابتکار تحول را به یک سناریوی اجرایی تبدیل کنید
برای نزدیکشدن برنامه تحول به اجرا، میتوان هر ابتکار را از این مسیر عبور داد:
ابتکار تحول ← مسئله مشخص ← مالک ← فرایند ← داده و سامانهها ← راهکار اجرایی ← شاخص موفقیت
این مسیر یک استاندارد رسمی تحول دیجیتال نیست؛ یک روش عملی برای تبدیل ابتکارهای کلی به موضوعاتی است که بتوان درباره اجرا و نتیجه آنها تصمیم گرفت.
یک مسئله مشخص انتخاب کنید
نقطه شروع نباید نام یک فناوری باشد.
ابتدا مشخص کنید چه چیزی در عملیات امروز باید تغییر کند و چرا.
مسئله باید بهاندازهای روشن باشد که تیم کسبوکار، فرایند و فناوری درباره یک موضوع مشترک صحبت کنند.
مالک نتیجه را تعیین کنید
مالک ابتکار فقط مسئول هماهنگی جلسات نیست.
باید مشخص باشد چه کسی درباره دامنه، اولویتها، فرایند مطلوب و معیار پذیرش تصمیم میگیرد یا مسیر تصمیمگیری را مدیریت میکند.
در پروژههای بینواحدی ممکن است ذینفعان متعددی وجود داشته باشند، اما مسئولیت تصمیم درباره نتیجه همچنان باید روشن باشد.
فرایند To-Be را تعریف کنید
وقتی مسئله و مالک مشخص شدند، باید نشان داد روش مطلوب انجام کار چیست.
این مرحله پلی میان نیاز مدیریتی و سامانه اجرایی است.
فرایند To-Be مشخص میکند در وضعیت آینده کار از چه مسیری عبور میکند، چه مسئولیتهایی وجود دارند، نقاط تصمیم کجا هستند و چه بخشهایی نسبت به وضعیت فعلی تغییر میکنند.
داده و Integration را مشخص کنید
در طراحی سناریوی اجرایی، داده و یکپارچهسازی با سامانهها باید از همان ابتدا دیده شوند.
اگر اجرای راهکار به یک پایگاه داده، سرویس بیرونی یا سامانه تخصصی وابسته است، این موضوع بخشی از دامنه پروژه است؛ نه جزئیاتی که بعداً بدون تحلیل به تیم فنی واگذار شود.
تیم فناوری اطلاعات در این مرحله نقش مهمی دارد، زیرا معماری، دسترسی و امکان یکپارچهسازی باید با شرایط واقعی زیرساخت سازمان سازگار باشند.
معیار پذیرش و KPI را قبل از اجرا تعریف کنید
یا شاخص کلیدی عملکرد مشخص میکند کدام جنبه از نتیجه برای سازمان اهمیت دارد.
معیار پذیرش نیز پاسخ میدهد چه شرایطی باید برقرار باشد تا صاحب فرایند یا کسبوکار راهکار را مناسب استفاده بداند.
این دو را نباید به پایان پروژه موکول کرد.
اگر معیار موفقیت بعد از دیدن نتیجه تعریف شود، ارزیابی پروژه بهسادگی میتواند تحت تأثیر برداشتهای متفاوت قرار گیرد.
چرا اجرای مرحلهای اهمیت دارد؟
یک برنامه تحول میتواند بسیار گسترده باشد، اما لازم نیست تمام دامنه آن در یک مرحله اجرا شود.
رویکرد مرحلهای کمک میکند ابتدا یک بخش مشخص به اجرای واقعی برسد، نتیجه آن مشاهده شود و سپس درباره توسعه دامنه تصمیم گرفته شود.
این رویکرد به سازمان اجازه میدهد از یک مسئله مشخص و قابلاندازهگیری شروع کند و تصمیمهای بعدی را با اطلاعات حاصل از اجرا دقیقتر کند.
دامنه نخست را محدود کنید
مرحله نخست باید بهاندازهای کامل باشد که نتیجه واقعی تولید کند و در عین حال قابل مدیریت باشد.
«محدود» به معنای انتخاب مسئلهای کماهمیت نیست.
یک سناریوی بینواحدی نیز میتواند نقطه شروع مناسبی باشد، اگر مرز، مسئولیتها و وابستگیهای اصلی آن روشن باشند.
هدف این است که مرحله نخست یک سؤال مشخص و قابل ارزیابی داشته باشد.
قبل از اجرا خط مبنا ثبت کنید
خط مبنا وضعیت پایهای است که نتیجه آینده با آن مقایسه میشود.
اگر هدف تغییر زمان انتظار، تعداد برگشتها یا تجربه کاربران است، باید پیش از اجرا حداقل داده لازم درباره وضعیت فعلی ثبت شود.
لازم نیست برای هر پروژه مجموعه بزرگی از شاخصها جمعآوری شود. خط مبنا باید متناسب با مسئلهای باشد که پروژه قرار است تغییر دهد.
نتیجه مرحله نخست را ارزیابی کنید
بعد از اجرای مرحله نخست، صرف تحویل سامانه کافی نیست.
باید بررسی شود آیا سناریوی موردنظر در عملیات کار میکند، کاربران میتوانند وظایف خود را انجام دهند و شاخصهای تعیینشده چه تصویری از نتیجه ارائه میکنند.
کیفیت اجرا، پذیرش کاربران و اثر عملیاتی میتوانند بخشی از این ارزیابی باشند.
سپس درباره توسعه دامنه تصمیم بگیرید
نتیجه مرحله نخست باید ورودی تصمیم بعدی باشد.
ممکن است سازمان تصمیم بگیرد همان راهکار را به واحدهای بیشتری توسعه دهد، یکپارچهسازی جدیدی اضافه کند، فرایند را اصلاح کند یا ابتدا مسئلهای را که در اجرای نخست آشکار شده برطرف کند.
در این مدل، نقشه راه همچنان جهت کلی را مشخص میکند، اما یادگیری حاصل از اجرا میتواند ترتیب و شیوه ادامه مسیر را دقیقتر کند.
نقش پلتفرم فرایندمحور در این مسیر چیست؟
تا اینجا تعریف مسئله، مالکیت، فرایند، داده و معیار موفقیت مستقل از انتخاب یک محصول خاص مطرح شدند.
از مرحلهای که سناریوی اجرایی روشن میشود، فناوری باید بتواند این طراحی را به سامانهای قابل استفاده تبدیل کند.
یک پلتفرم فرایندمحور میتواند زیرساخت اجرایی بخشی از برنامه تحول باشد.
در گراف BPMS، مدل فرایند میتواند به فرم، نقشها، قواعد، منابع داده و سرویسها متصل شود و اطلاعات حاصل از اجرا نیز در گزارشها مورد استفاده قرار گیرد.
این قابلیت به تیمها امکان میدهد بخشی از ابتکارهای تحول را از سطح طراحی به فرایندها و سامانههای عملیاتی نزدیک کنند. خود پلتفرم جایگزین راهبری تحول، مدیریت تغییر یا تصمیمهای کسبوکاری سازمان نیست.
از مدل فرایند به اجرای واقعی
مدل فرایند زمانی ارزش عملی بیشتری پیدا میکند که منطق آن بتواند وارد جریان واقعی کار شود.
در گراف BPMS، فرایند طراحیشده میتواند به اجزای اجرایی متصل شود تا فعالیتها، مسئولیتها و تصمیمهای مشخصشده در طراحی وارد جریان کار شوند.
ارتباط با داده و سامانههای موجود
برنامه تحول الزاماً به معنای کنارگذاشتن تمام سامانههای موجود نیست.
در بسیاری از سناریوها، راهکار جدید باید در کنار زیرساخت فعلی کار کند و اطلاعات موردنیاز را از منابع دیگر دریافت یا به آنها ارسال کند.
گراف BPMS روشهایی برای اتصال فرایند به سرویسها و منابع داده دارد. امکان اتصال هر سامانه مشخص نیز به معماری، API، پروتکلها و مجوزهای همان سامانه وابسته است.
داده اجرای واقعی برای مرحله بعدی بهبود
یکی از تفاوتهای مهم میان فرایند طراحیشده و فرایند اجراشده، دادهای است که در عملیات تولید میشود.
بعد از اجرا میتوان وضعیت فعالیتها و اطلاعات مرتبط با فرایند را در گزارشها مشاهده و برای تحلیل استفاده کرد.
این داده میتواند ورودی تصمیمهای بعدی درباره اصلاح فرایند باشد و مسیر تحول را از یک پروژه یکباره به چرخهای از طراحی، اجرا، مشاهده و بهبود نزدیک کند.
فناوری کجای تحول دیجیتال قرار میگیرد؟
پرسش اصلی نباید این باشد که «کدام فناوری جدیدتر است؟»
پرسش بهتر این است که:
برای مسئله، معماری و دامنه اجرایی ما چه فناوریای لازم است؟
هوش مصنوعی، رایانش ابری، تحلیل داده یا BPMS میتوانند در برنامههای مختلف نقش داشته باشند، اما انتخاب آنها باید از مسئله واقعی و معماری موردنیاز آغاز شود.
ممکن است یک ابتکار بیش از هر چیز به یکپارچهسازی داده نیاز داشته باشد و دیگری به بازطراحی فرایند یا ابزار تحلیلی.
تبدیل فناوری به هدف میتواند ترتیب تصمیمگیری را معکوس کند: ابتدا ابزار انتخاب میشود و بعد سازمان تلاش میکند مسئلهای برای آن پیدا کند.
فناوری باید توانمندساز اجرای تغییر باشد؛ نه جایگزین تعریف مسئله، راهبری، طراحی فرایند یا مدیریت تغییر.
تحول دیجیتال بدون مدیریت تغییر کامل نمیشود
سامانه جدید ممکن است آماده باشد، اما اگر افراد سازمان ندانند چرا روش کار تغییر کرده و مسئولیت جدید آنها چیست، فاصله دیگری میان طراحی و استفاده واقعی ایجاد میشود.
مدیریت تغییر فقط برگزاری یک جلسه آموزشی در انتهای پروژه نیست.
کاربران را فقط در انتهای پروژه وارد نکنید
کاربران عملیاتی جزئیاتی از اجرای واقعی میدانند که ممکن است در مستندات فرایند دیده نشوند.
مشارکت آنها در طراحی و آزمون میتواند استثناها، ابهامها و مسائل کاربری را پیش از بهرهبرداری آشکار کند.
این مشارکت به معنای واگذاری تصمیم معماری یا حاکمیت پروژه به کاربران نیست؛ هدف، استفاده از تجربه کسانی است که قرار است با راهکار کار کنند.
انتقال دانش را بخشی از استقرار بدانید
اگر تمام دانش تحلیل، تنظیم و تغییر راهکار فقط نزد تیم بیرونی باقی بماند، اصلاحات آینده نیز به همان وابستگی اولیه گره میخورند.
آموزش و انتقال دانش به تیم داخلی کمک میکند سازمان در ادامه مسیر، درک بیشتری از منطق راهکار و شیوه توسعه تدریجی آن داشته باشد.
در پروژههای گراف BPMS نیز آموزش و انتقال دانش میتوانند در کنار تحلیل و استقرار قرار گیرند تا تیم سازمان برای ادامه کار و توسعه تدریجی راهکار آمادهتر شود.
مالکیت تغییر باید داخل سازمان باقی بماند
فناوری و شریک اجرایی میتوانند ابزار، تجربه و پشتیبانی ارائه کنند، اما تصمیم درباره اینکه چه چیزی باید تغییر کند و چه نتیجهای مطلوب است باید در سازمان مالک داشته باشد.
مدیریت ارشد، مالک فرایند، تیم تحول و فناوری اطلاعات هرکدام بخشی از این حاکمیت را بر عهده دارند.
این مالکیت داخلی کمک میکند تحول از یک پروژه فناوری به بخشی از سازوکار تصمیمگیری و بهبود سازمان تبدیل شود.
یک چارچوب عملی برای تبدیل برنامه به اجرا
برای یک ابتکار مشخص میتوان این مسیر را بهعنوان چارچوب کاری اولیه در نظر گرفت:
- مسئله کسبوکاری را مشخص کنید. قرار است چه چیزی در عملیات تغییر کند؟
- دامنه مرحله نخست را محدود کنید. اولین اجرای واقعی دقیقاً کدام بخش را پوشش میدهد؟
- مالک و ذینفعان را تعیین کنید. چه کسی مسئول نتیجه است و چه کسانی در تصمیمها نقش دارند؟
- فرایند To-Be را طراحی کنید. روش مطلوب انجام کار بعد از تغییر چیست؟
- داده و سامانههای درگیر را مشخص کنید. راهکار به چه اطلاعات و یکپارچهسازیهایی وابسته است؟
- شاخص موفقیت و Baseline را تعیین کنید. وضعیت فعلی چیست و نتیجه آینده با چه معیاری سنجیده میشود؟
- یک راهکار قابل استفاده پیادهسازی کنید. سناریو باید از سطح طراحی به اجرای واقعی برسد.
- نتیجه را با داده و بازخورد واقعی ارزیابی کنید. تحویل فنی را از نتیجه عملیاتی جدا ببینید.
- مرحله بعد را براساس نتیجه تعریف کنید. دامنه را توسعه دهید، اصلاح کنید یا اولویت بعدی را انتخاب کنید.
این مراحل یک چارچوب پیشنهادی برای تصمیمگیری و اجرا هستند و قرار نیست بهعنوان استاندارد رسمی تحول دیجیتال تلقی شوند.
پرسشهای متداول
آیا خرید BPMS به معنای تحقق تحول دیجیتال است؟
خیر.
BPMS میتواند یکی از زیرساختهای اجرای سامانههای فرایندمحور در برنامه تحول باشد، اما نتیجه به مسئله انتخابشده، راهبری، طراحی فرایند، داده، مدیریت تغییر و مشارکت کاربران نیز وابسته است.
آیا تحول دیجیتال باید یک پروژه بزرگ سازمانی باشد؟
نه الزاماً.
ممکن است نقشه راه تحول دامنه گستردهای داشته باشد، اما اجرای آن میتواند مرحلهای باشد. یک مسئله مشخص انتخاب میشود، نتیجه مرحله نخست ارزیابی میشود و سپس درباره توسعه دامنه تصمیم گرفته میشود.
این رویکرد امکان یادگیری از اجرای واقعی را پیش از گسترش پروژه فراهم میکند.
اولین پروژه تحول را از کجا شروع کنیم؟
از مسئلهای که برای سازمان ارزش مشخص دارد و میتوان دامنه و نتیجه آن را تعریف کرد.
اگر چند فرایند کاندید دارید، مقاله «کدام فرایند را اول دیجیتالی کنیم؟» معیارهای انتخاب نقطه شروع را بررسی میکند.
[ARTICLE_02_URL]
چگونه نتیجه یک ابتکار تحول را ارزیابی کنیم؟
ابتدا Baseline یا وضعیت پایه را ثبت کنید و KPIهای متناسب با مسئله را مشخص کنید.
پس از اجرا، علاوه بر عملکرد فنی سامانه، پذیرش کاربران و تغییر قابل مشاهده در عملیات را بررسی کنید.
اینکه چه چیزی باید سنجیده شود به هدف همان ابتکار بستگی دارد؛ بنابراین یک مجموعه ثابت از شاخصها برای همه پروژهها مناسب نیست.
نقش تیم فناوری اطلاعات و تیم فرایند چیست؟
تیم فرایند و کسبوکار باید مسئله، منطق اجرایی و نتیجه مطلوب را روشن کنند.
تیم فناوری اطلاعات نیز نقش مهمی در معماری، یکپارچهسازی، دسترسیها و سازگاری راهکار با زیرساخت سازمان دارد.
مدل مناسب، همکاری این دو حوزه است؛ نه اینکه تحول فقط پروژه فناوری اطلاعات یا فقط پروژه واحد کسبوکار تلقی شود.