Аналіз бізнес-процесів перед розробкою, впровадженням чи рішенням про розробку чи впровадження інформаційних систем — чому це важливо.
Інколи трапляється так, що більш-менш детальний аналіз та опис бізнес-процесів в компанії відбувається лише тоді, коли туди приймається рішення про розробку та/чи впровадження якоїсь важливої інформаційної системи (далі — ІС). Тоді в компанію приходить (чи приходять) бізнес-аналітик від розробника і, щоб точніше виявити бізнес-потреби і сформулювати всі вимоги, проводить певну велику роботу, яка також включає певною мірою аналіз та опис бізнес-процесів.
Розглянемо таку ситуацію більш детально.
Перш за все, зазначимо, що основний "практичний" результат роботи бізнес-аналітика в даному випадку — це технічне завдання для розробників, а також все, що цього напряму стосується, — описи, обгрунтування і т.і. з одного боку та супровід і аналіз з іншого.
Компанія-розробник (чи яка займається впровадженням) отримує гроші не за якісний опис та аналіз бізнес-процесів замовника, а за розробку та/чи впровадження ІС. Для їх бізнес-аналітика задачі оптимізації та управління процесами — в кращому випадку попутні і другорядні в порівнянні з основною задачею.
Це не звинувачення — розробник обмежений бюджетом і виконує свою роботу. Загалом, процеси — це справа самої компанії.
Чому важливо розуміти свої процеси до спілкування з компанією-розробником легше побачити на тому, що трапляється досить часто: в ході проекту компанія-замовник може з'ясувати, що вони працюють не зовсім так, як це гадалось, — чи хочуть працювати не так, як завжди. І треба вносити правки у вимоги, у юзер-кейси, в проект в цілому. Це додаткові витрати, втрата часу, проблеми з виконавцями (хоч для них це не рідка ситуація). Аналітик від розробника наче врахував всі т.зв. нефункціональні вимоги, але ІС покривала один аспект роботи компанії, а згодом виявилось, що це впливає також на інші, тому з'являються нові суттєві вимоги, і нефункціональні, і функціональні, можуть зміститись приорітети, змінюються юзер кейси (чи змінюється та/або доповнюється список юзер сторіз, в залежності від того, за якими методиками працює аналітик). При цьому замовник не факт, що задоволений, бо запланована ідеальна структура починає нагадувати на дім, де то тут, то там виникають пристройки, а можливо навіть підпорки під стіни.
Інший аспект — інтеграція з іншими системами. Буває, особливо, коли у компанії-замовника це перший масштабний проект, керівництво хоче бачити максимум в новій системі. Все виглядає добре, але на якомусь етапі стає зрозуміло, що дані треба також і тим підрозділам, щодо яких на початку проекту здавалось, що їх це не торкнеться. І що формати даних, запитів та звітів побудовані трохи інакше. І було б непогано, якщо потрібні дані були доступні також іншим працівникам, інтереси яких не враховувались через спеціфіку проекту, але з певними обмеженнями прав доступу.
А ще може виявитись, що не виходить відмовитись повністю від старих баз даних. І що нова система побудована, як і задумувалось, з огляду на певний аспект бізнесу (наприклад, управління ресурсами), а треба також якось інтегрувати це з іншими, які на початку задумувались як паралельні (наприклад, управління продажем).
Також досить часто трапляється, що або в ході проекту, або після його завершення, виявляється, що не врахований ріст компанії в цілому і створення або підключення нових систем. І тоді може трапитись, що база даних, вбудована в нову ІС, вже не така й зручна з огляду на використання її іншими системами.
Причому, не рідко аналітики прямо ставлять питання про можливий розвиток та інтеграцію з іншими системами — але, якщо у стейкхолдерів від компанії-замовника нема повного бачення, вони можуть це бачити по-різному на початку та в кінці проекту. Тобто це не вина компанії-розробника, що замовник не бачить картину в цілому і не зовсім розуміє, що саме буде потрібно додатково чи в ході розвитку.
Зрозуміло, і певний інтерес виконавців також не варто виключати. В рекламних проспектах та презентаціях може бути написано і сказано багато, а в реальності функціонал може бути в наявності, але не такий, як це уявлялось. І, що гірше, може не співпадати з реальними процесами, що замість поліпшення лише ускладнить роботу.
І тоді може виявитись, що зберігання файлів та посилань на них в ІС не замінить електронний документообіг, а ЕД не замінить управління проектами. І що ERP, не дивлячись на те, що там є всі дані по клієнтам, не замінює CRM систему, хоча так може здаватись на якомусь етапі, і навпаки, "розвинута" CRM система, попри те, що там може бути у якомусь вигляді склад, зберігання документів та багато іншого, не підходить для повноцінного управління ресурсами.
Як приклад: в деяких IT-компаніях, особливо невеликих, в якості CRM-систем використовують системи по управлінню проектами. Логіка така: якщо з клієнтом вже працюють, то це вже проект, нехай на дуже початковій стадії.
Але, фактично, виявляється, що процеси пошуку клієнтів, допродажу, супровіду (на рівні продавця, а не проджект-менеджера) взагалі "випадають". По цим процесам нема ні автоматизації, ні навіть звітності, клієнти просто якось "з'являються" в системі, невідомо як, хтось з ними про щось спілкується, але в ІС потрапляють лише результативні випадки.
Логічне питання: тобто аналіз бізнес-процесів має сенс лише в "широкому" сенсі, щоб побачити загальну картину? Ні, не обов'язково. Це не обов'язково всі процеси, може бути частина або взагалі один. Різниця між аналізом власних процесів та аналізом з боку аналітика від розробника перш за все в кінцевій меті: розробник хоче якісно розробити/впровадити ІС, процеси для нього річ другорядна, якщо взагалі мають значення (потреби добре видно і без опису процесів, для цього може бути достатньо юзер кейсів чи юзер сторіз + опис нефункціональних вимог і т.і.)
Тоді як інтерес компанії перш за все в розумінні власних процесів з огляду на ефективне управління ними.
До речі, деякі компанії-замовники взагалі не відкривають свої процеси розробникам. По-перше, з огляду на конфіденційнійсть, по-друге — зазвичай це дуже розвинуті компанії, які і добре знають свої процеси, і знають, чого саме вони хочуть від розробників, і усвідомлюють те, що не кажуть розробникам.
Але якщо такого розуміння нема, то створення/впровадження нової системи може спіткнутись з розпливчатими вимогами замовника, які можуть в процесі змінюватись, іноді дуже кардинально, або навіть привести до негативного результату.
Інколи трапляється так, що більш-менш детальний аналіз та опис бізнес-процесів в компанії відбувається лише тоді, коли туди приймається рішення про розробку та/чи впровадження якоїсь важливої інформаційної системи (далі — ІС). Тоді в компанію приходить (чи приходять) бізнес-аналітик від розробника і, щоб точніше виявити бізнес-потреби і сформулювати всі вимоги, проводить певну велику роботу, яка також включає певною мірою аналіз та опис бізнес-процесів.
Розглянемо таку ситуацію більш детально.
Перш за все, зазначимо, що основний "практичний" результат роботи бізнес-аналітика в даному випадку — це технічне завдання для розробників, а також все, що цього напряму стосується, — описи, обгрунтування і т.і. з одного боку та супровід і аналіз з іншого.
Компанія-розробник (чи яка займається впровадженням) отримує гроші не за якісний опис та аналіз бізнес-процесів замовника, а за розробку та/чи впровадження ІС. Для їх бізнес-аналітика задачі оптимізації та управління процесами — в кращому випадку попутні і другорядні в порівнянні з основною задачею.
Це не звинувачення — розробник обмежений бюджетом і виконує свою роботу. Загалом, процеси — це справа самої компанії.
Чому важливо розуміти свої процеси до спілкування з компанією-розробником легше побачити на тому, що трапляється досить часто: в ході проекту компанія-замовник може з'ясувати, що вони працюють не зовсім так, як це гадалось, — чи хочуть працювати не так, як завжди. І треба вносити правки у вимоги, у юзер-кейси, в проект в цілому. Це додаткові витрати, втрата часу, проблеми з виконавцями (хоч для них це не рідка ситуація). Аналітик від розробника наче врахував всі т.зв. нефункціональні вимоги, але ІС покривала один аспект роботи компанії, а згодом виявилось, що це впливає також на інші, тому з'являються нові суттєві вимоги, і нефункціональні, і функціональні, можуть зміститись приорітети, змінюються юзер кейси (чи змінюється та/або доповнюється список юзер сторіз, в залежності від того, за якими методиками працює аналітик). При цьому замовник не факт, що задоволений, бо запланована ідеальна структура починає нагадувати на дім, де то тут, то там виникають пристройки, а можливо навіть підпорки під стіни.
Інший аспект — інтеграція з іншими системами. Буває, особливо, коли у компанії-замовника це перший масштабний проект, керівництво хоче бачити максимум в новій системі. Все виглядає добре, але на якомусь етапі стає зрозуміло, що дані треба також і тим підрозділам, щодо яких на початку проекту здавалось, що їх це не торкнеться. І що формати даних, запитів та звітів побудовані трохи інакше. І було б непогано, якщо потрібні дані були доступні також іншим працівникам, інтереси яких не враховувались через спеціфіку проекту, але з певними обмеженнями прав доступу.
А ще може виявитись, що не виходить відмовитись повністю від старих баз даних. І що нова система побудована, як і задумувалось, з огляду на певний аспект бізнесу (наприклад, управління ресурсами), а треба також якось інтегрувати це з іншими, які на початку задумувались як паралельні (наприклад, управління продажем).
Також досить часто трапляється, що або в ході проекту, або після його завершення, виявляється, що не врахований ріст компанії в цілому і створення або підключення нових систем. І тоді може трапитись, що база даних, вбудована в нову ІС, вже не така й зручна з огляду на використання її іншими системами.
Причому, не рідко аналітики прямо ставлять питання про можливий розвиток та інтеграцію з іншими системами — але, якщо у стейкхолдерів від компанії-замовника нема повного бачення, вони можуть це бачити по-різному на початку та в кінці проекту. Тобто це не вина компанії-розробника, що замовник не бачить картину в цілому і не зовсім розуміє, що саме буде потрібно додатково чи в ході розвитку.
Зрозуміло, і певний інтерес виконавців також не варто виключати. В рекламних проспектах та презентаціях може бути написано і сказано багато, а в реальності функціонал може бути в наявності, але не такий, як це уявлялось. І, що гірше, може не співпадати з реальними процесами, що замість поліпшення лише ускладнить роботу.
І тоді може виявитись, що зберігання файлів та посилань на них в ІС не замінить електронний документообіг, а ЕД не замінить управління проектами. І що ERP, не дивлячись на те, що там є всі дані по клієнтам, не замінює CRM систему, хоча так може здаватись на якомусь етапі, і навпаки, "розвинута" CRM система, попри те, що там може бути у якомусь вигляді склад, зберігання документів та багато іншого, не підходить для повноцінного управління ресурсами.
Як приклад: в деяких IT-компаніях, особливо невеликих, в якості CRM-систем використовують системи по управлінню проектами. Логіка така: якщо з клієнтом вже працюють, то це вже проект, нехай на дуже початковій стадії.
Але, фактично, виявляється, що процеси пошуку клієнтів, допродажу, супровіду (на рівні продавця, а не проджект-менеджера) взагалі "випадають". По цим процесам нема ні автоматизації, ні навіть звітності, клієнти просто якось "з'являються" в системі, невідомо як, хтось з ними про щось спілкується, але в ІС потрапляють лише результативні випадки.
Логічне питання: тобто аналіз бізнес-процесів має сенс лише в "широкому" сенсі, щоб побачити загальну картину? Ні, не обов'язково. Це не обов'язково всі процеси, може бути частина або взагалі один. Різниця між аналізом власних процесів та аналізом з боку аналітика від розробника перш за все в кінцевій меті: розробник хоче якісно розробити/впровадити ІС, процеси для нього річ другорядна, якщо взагалі мають значення (потреби добре видно і без опису процесів, для цього може бути достатньо юзер кейсів чи юзер сторіз + опис нефункціональних вимог і т.і.)
Тоді як інтерес компанії перш за все в розумінні власних процесів з огляду на ефективне управління ними.
До речі, деякі компанії-замовники взагалі не відкривають свої процеси розробникам. По-перше, з огляду на конфіденційнійсть, по-друге — зазвичай це дуже розвинуті компанії, які і добре знають свої процеси, і знають, чого саме вони хочуть від розробників, і усвідомлюють те, що не кажуть розробникам.
Але якщо такого розуміння нема, то створення/впровадження нової системи може спіткнутись з розпливчатими вимогами замовника, які можуть в процесі змінюватись, іноді дуже кардинально, або навіть привести до негативного результату.
No comments:
Post a Comment