Реорганізація бізнес-процесів при зміні інформаційної системи у великій організації

Реорганізація бізнес - процесів при зміні інформаційної системи у великій організації.

Зміст:

1. Концепція інформаційної системи та вимоги які можуть до неї пред'являтися
2. Типи змін інформаційної системи
3. Принципи планування проекту по зміні інформаційної системи
4. Принципи формування та роботи команди, яка відповідає за зміну інформаційної системи, підбір її учасників і взаємини з організацією

1. Концепція інформаційної системи та вимоги які можуть до неї пред'являтися
В даний час поняття інформаційної системи настільки розмито, що підінформаційною системою може бути визначено будь-яке поняття від комп'ютерноїпрограми, яка допомагає автоматизувати якийсь процес, до сложівщегосянабору правил і процедур, що регламентують дії співробітників компанії зорганізації процесів створення та використання інформації в потрібному длякомпанії вигляді.

Тому не ставлячи перед собою завдання розглянути всі можливі визначеннядля інформаційної системи, автор запропонував би1 розуміти під інформаційноїсистемою інтегровану базу даних, що дозволяє завдяки своїйфункціональності обробляти широкий спектр бізнес процесів, в якийможуть входити наступні (оскільки дана робота пов'язана з участю авторав конкретному проекті з інтеграції нової інформаційної системи у великійкомпанії, певні галузі діяльності організації могли не увійти доданий список, як наприклад кадровий облік, деякі фінансові,бухгалтерські та логістичні аспекти, маркетинг тощо):
. процес прийому замовлень
. облік складського інвентарю
. облік транспортувань продукції
. процес закупівель продукції
. процес митного очищення продукції
. бухгалтерське відображення всіх зазначених процесів
. облік рахунків до отримання
. облік рахунків для виплати
. облік витрат і т.д.

__________________< br>1Поскольку вибір даної теми був обумовлений участю автора в проекті, підв чому відображає тенденції щодо зміни інформаційних систем у великихкомпаніях, автор вважав за можливе розглядати процес переходу великихкомпаній до нової інтегрованої бази даних з широкою функціональністю підчому типовим, а отже і саму базу даних (поступовозавойовують ринок «великих» інформаційних систем) типовою і найбільшпідходить під визначення інформаційної системи.
Що стосується функціональності інформаційної системи, то ознакою
«Системності» автор запропонував би вважати ступінь розробленості даноїфункціональності. Чим більше областей діяльності організації охоплюєдана конкретна база даних, і чим більше функціональних можливостей пообліку нестандартних «життєвих ситуацій» ця база даних надає, тимближче її можна віднести до інформаційної системи. Природно інформаційнасистема повинна бути здатна обробляти достатні обсяги інформації
(визначаються розміром бізнесу конкретної організації) за відноснокороткий час.

Під «інтегрованість» інформаційної системи можна розуміти ступіньпов'язаності всіх процесів організації, які знайшли відображення в системі,в єдине ціле. Типовим прикладом інтегрованої системи може бутисистема, яка дозволяє враховувати і логістичні, і бухгалтерськіпроцеси. Наприклад, при оформленні в системі замовлення, який робитьзамовник, в системі виникає відповідна бухгалтерська проводка,збільшуються рахунку до отримання та зменшується кількість товару на складі,яка має статус вільного використання.

Запропонувавши розуміти під інформаційною системою описане вище іобмежуючись перерахуванням факторів, властивих інформаційній системі,автор дав би неповне уявлення про неї. Однією з найважливіших компонент,безпосередньо пов'язаних з інформаційними системами, є люди,використовують систему в своїх цілях, і процеси, що регламентуютьдіяльність співробітників з використання системи. Організація данихпроцесів і навчання співробітників роботі з системою є ключовоюпередумовою успішного функціонування системи і будуть описані нижче приописі зміни інформаційної системи.
2. Типи змін інформаційної системи
Зміни інформаційної системи можна класифікувати в залежності віддекількох факторів. Під такими факторами автор запропонував би розумітинаступні:
1. вид зміни інформаційної системи
2. причина зміни інформаційної системи
3. область зміни інформаційної системи
4. масштаб залучення ресурсів.
Опишемо кожен з факторів більш детально, зробивши застереження, що позаЗалежно від фактора або типу зміни кожен проект, що належить дозміни інформаційної системи, має свої настільки унікальні риси,що навряд чи можливо знайти два абсолютно ідентичних проекту в цій галузі.
Це в першу чергу можна пояснити специфікою та унікальністю внутрішньоїорганізації бізнес-процесів в кожної компанії, а також видом їїдіяльності.

1. Вид зміни інформаційної системи
Тут мається на увазі, наскільки якісно сильним і радикальним єзміна. Можна умовно виділити такі типи змін:
. Установка системи з нуля за відсутності якої-небудь попередньої системи
(установка з нуля).
Тут суттєвим моментом є те, що бізнес процеси не були автоматизовані, а впровадження системного підходу до ведення бізнесу вимагає автоматизації. У принципі, цей тип доцільно застосовувати тоді, коли обсяги бізнесу такі, що вже стає важко керувати ними і аналізувати їх на винятковій основі (тобто кожна подія окремо). Потрібен якийсь механізм, що дозволяє стандартизувати показники, за якими відбувається аналіз ефективності діяльності організації.
. Розширення функціональних можливостей існуючої системи (розширення функцій).
Така зміна можлива в двох випадках. У першому випадку ті процеси, які потрапляють під розширені функціональні можливості системи, починають вимагати стандартного системного підходу, як описано в попередньому пункті. Другий випадок відбувається тоді, коли ті процеси, які не відстежувалися в системі, раніше відстежувалися в іншій системі.
Це відбувається, якщо інша система стає неефективною, а та система, у якої розширюються функціональні можливості, дозволяє відслідковувати дані процеси ефективно. До особливостей цього типу змін відноситься необхідність ретельного вивчення можливостей додаткової функціональності системи та її адаптація до процесів в організації, де особливо важливо врахувати підготовку персоналу до роботи з системою.
. Відчуження частини функціональних можливостей існуючої системи
(відчуження функцій).
Такого типу зміни можливі у разі зміни діяльності організації
(зокрема, якщо якийсь із процесів, що існували раніше і відігравали важливу роль, перестає бути актуальним). Наприклад, при будівництві заводу припиняється імпорт продукції, що призводить до того, що процес розмитнення зникає, і його ефективність не відстежується, що в свою чергу призводить до відчуження митного модуля інформаційної системи.
. Установка нової інформаційної системи при збереженні частини функціональності старої системи (прибудова системи).
Тут можливий варіант, коли нова система існує як надбудова до старої та виконує частину функцій, які раніше виконувала стара система або виконує частину нових функцій. Тут, як і в попередньому розділі, слід особливу увагу звернути вивчення можливостей нової системи, навчання персоналу, а також організації комунікації даних між двома системами.
. Установка нової інформаційної системи при повному відчуженні старої системи (повна зміна системи).
Це одна з найбільш складних проектів, тому що при його реалізації слід враховувати відразу весь комплекс факторів:

- вивчення процесів організації для проведення аналізу при тестуванні нової системи;

- вивчення можливостей нової системи в порівнянні зі старою стосовно до процесів організації;

- моделювання тестових ситуацій;

- тестування нової системи як у попередньому режимі, так і в режимі роботи з реальними даними, аж до подвійного введення даних - в нову і стару систему одночасно;

- прийняття рішень щодо змін в процесах, які можна здійснити при зміні системи;

- підготовка менеджменту та персоналу до проведення змін у процесах;

- навчання персоналу роботі з новою системою;

- планування переходу зі старої системи на нову при збереженні правильності даних та їх обліку;

- підтримка нормального функціонування нової системи найближчим часом після переходу і надалі.
. Встановлення системи, яка виконує роль інтерфейсу між двома існуючими, але не сумісними раніше системами (установка інтерфейсу).
Для такого типу змін характерна необхідність проведення тренінгів для персоналу з роз'яснення основних змін при роботі з системами щодо нових можливостей, які з'являються при створенні інтерфейсу, а також ретельне планування технічних розробок інтерфейсу.

2. Причина зміни інформаційної системи
Причина зміни інформаційної системи дозволяє визначити, чомувідбулася зміна системи в організації. Як приклади можна привестиряд найбільш поширених причин, по яких відбуваються зміни вінформаційній системі:
. технічні характеристики системи (швидкодія, здатність обробляти певні обсяги інформації, сумісність з існуючими системами, зручність використання). Тут ключову роль відіграє критичність технічних здібностей системи - якщо стара система не в змозі обробляти що вводиться в неї інформацію з потрібною швидкістю, то тоді дана причина є однією з основних, через які відбувається зміна або зміна інформаційної системи.
. область діяльності організації (поява нових процесів або зникнення старих). Зміна діяльності призводить до зміни процесів, у процесах вимагає зміни в системі.
. функціональність системи (набір функцій, які може підтримувати система - від обробки інформації до конкретних процесів, які можна відслідковувати в системі). Безпосередньо пов'язана з областю діяльності організації та розміром бізнесу. При зміні діяльності організації відбувається зміна функціональності системи, при зміні розміру бізнесу може виникнути або відпасти необхідність систематичного і електронної реєстрації інформації (наприклад, якщо фірма виробляє всього кілька відвантажень в день, то не варто зберігати статистики по тому, як якісно прибуває транспорт до замовника -- під час/не під час, якщо ж фірма відвантажує по 40-50 або більше вантажівок до замовників, то в цьому випадку просто необхідно вести статистику по кількості запізнень і працювати з поліпшення показників, інакше якість сервісу може почати поступово погіршуватися, що потенційно може призвести до втрати покупців).
. моральне старіння системи (стара версія змінюється на нову).
Досить поширена ситуація, часто буває так, що нова версія інформаційної системи не тільки зручніше у використанні, але і надає більш досконалі технічні характеристики і більш широку функціональність.
. політика організації щодо стандартизації процесів в різних відділеннях організації (підведення всіх процесів під один стандарт і як наслідок установка стандартної інформаційної системи). Дана причина характерна для компаній з великою кількістю філій. Якщо компанія прагне до стандартизації бізнес процесів (що має ряд істотних переваг, таких як економія на використанні єдиного формату процесів і обробки даних, впровадження передового досвіду, економія при організації бізнес-процесів в нових філіях, широкі можливості для розвитку і переміщення співробітників між філіями і т . д.), то для неї крім організації єдиного стандарту реалізації бізнес процесів ще й необхідно встановити єдину систему, яка буде механізмом з реалізації стандартного підходу, а також інструментом інтеграції даних для аналізу.
. інтеграція різних областей діяльності організації (приклад - інтеграція в одну системи бухгалтерії та логістики). Дана причина пов'язана з можливістю економії на витратах ресурсів з ведення даних при об'єднанні різних процесів, що реєструються в організації на системному рівні.
. престижність використання нової системи. Може бути конкурентною перевагою для організацій, що працюють у сфері інформаційних технологій або послуг (особливо у сфері послуг з надання інформації).

3. Область зміни інформаційної системи
Під областю зміни інформаційної системи пропонується розуміти тусферу інформаційної системи, яка відноситься до певної системибізнес-процесів в діяльності організації. Грунтуючись на досвіді,отриманому автором під час роботи, можна визначити наступний базовийнабір сфер інформаційної системи:

. логістика

. бухгалтерський облік

. фінансовий аналіз

. облік кадрів

. маркетинг

. продажу/покупці

. звітність
Навряд чи є сенс описувати складові кожного елемента запропонованогобазового набору, тому що по-перше, кожна організація має своюунікальною специфікою, а отже далеко не кожна організаціяідеально підпадала б під детально розписаний базовий набір, а по-друге,опис зажадало б занадто багато уваги, що змінило б внутрішнюлогіку даної роботи і її мета - опис змін, які можутьвиникнути в організації зі зміною інформаційної системи.

4. Масштаб залучення ресурсів.
Зміна інформаційної системи можна також охарактеризувати з точкизору тих ресурсів, які залучені до процесу зміни інформаційноїсистеми і співвідношення залучення цих ресурсів. Під ресурсами відзапропонував би розуміти наступні невід'ємні складові будь-якого проекту, втому числі і проекту по зміні інформаційної системи:

. люди

. час

. набір функцій, які треба буде поміняти/впровадити

. вартість (бюджет).
Важливу роль тут відіграє співвідношення залучення ресурсів в проект. Цеє свого роду якісним показником стилю проведення змін вкомпанії, а також може дозволити оцінити ефективність менеджменту,що застосовується до проекту - природно при детальному вивченні даногоконкретного проекту. Якщо управління проектом організовано грамотно ідетально продумано, співвідношення залучення ресурсів може датиуявлення про те,

. наскільки проект є складним з технічної точки зору,

. наскільки складним є сам процес зміни інформаційної системи,

. наскільки інтенсивними або навіть агресивними є плани з реалізації проекту,
. наскільки дорогим є проект,
. наскільки в цілому проект важливий для організації і т.д.

Якщо розглядати масштаб залучення та використання ресурсів, то тутключовим буде визначення того, наскільки великий він для організації.
Враховуючи, що неможливо вказати загальні характеристики та критерії того,яке залучення ресурсів в абсолютному вираженні є великим, а якені, можна запропонувати використовувати набір суб'єктивних факторів, якіможуть дати основу для визначення величини масштабу використання ресурсів.
До таких факторів можна віднести наступні:
. частка співробітників компанії, які беруть безпосередню участь у проекті,
. частка співробітників компанії, в тому або іншому ступені залучених в проект,
. кількість функцій, які будуть підтримуватися нової інформаційної системою (якщо це не відторгнення певного набору функцій існуючої системи),
. якісний зміст функціональності, її складність і охоплення бізнес процесів,
. частка бюджету, відведеного на реалізацію проекту,
. вартість проекту щодо вартості інших проектів, що здійснюються в організації на даний момент,
. часові рамки проекту, його тривалість.

Відповідно на основі перерахованих вище факторів масштаб залученостіресурсів можна умовно розділити на

. великий,

. середній і

. маленький.

5. Позиціонування типу вимірюв?? ения інформаційної системи:
З нашої точки зору для певних цілей має сенс проводитипозиціонування типу зміни інформаційної системи. Це можна робитидля того, щоб мати можливість порівняння запланованого проекту заналогічним, проведеним раніше даній або іншою компанією. Цей формальниймеханізм може виявитися дуже корисним, тому що допомагає швидковизначити, з яким ступенем точності можна переймати досвід при аналізіаналогічного проекту. Природно ретельне вивчення одного або кількохінших проектів дуже корисно, а в деяких випадках може допомогти взначної економії коштів, але при первинній оцінці необхідноотримати якесь формальне подання про те, якого роду проект має бутипровести організації і в якому співвідношенні з іншими подібними проектами вінзнаходиться.

Запропонована матриця містить два типи змін, які висловлюють свогороду "ступінь серйозності" проекту, тобто масштаб залучення ресурсіві величину або ступінь даних змін, тобто вид зміниінформаційної системи (рис 2.1).

При цьому це позиціонування має проводитися разом з аналізомобласті зміни інформаційної системи, то є якісним аналізомзмін, що проводяться. Якісний аналіз - невід'ємна частина визначеннянабору функціональності проекту в початковій його стадії, а також основа приплануванні даного проекту.

рис. 2.1. Матриця для позиціонування типу зміни інформаційноїсистеми.
3. Принципи планування проекту по зміні інформаційної системи
Планування проекту є базовим процесом, на основі якоговідбувається все розвиток і реалізація проекту. Планування можна розбити надва типи: початкове планування і планування в процесі здійсненнясамого проекту. Початкове планування починається після того, як робитьсявисновок про необхідність проведення змін в інформаційній системіорганізації і закінчується, коли план проекту узгоджений з усімаучасниками проекту, від яких залежатиме його реалізація (менеджерипроекту і функціональних груп, яких торкнеться зміна інформаційноїсистеми). Планування в процесі здійснюється при необхідності внесеннязмін до проекту і є робочим процесом, що залежать від виконанняпланів реалізації проекту. Розглянемо детальніше кожен тип плануванняпроекту.

Початкове планування проекту.
Спочатку коротко розглянемо процес ухвалення рішення про проведення змін доінформаційній системі. (Слід зазначити, що початкова стадія будь-якогопроекту, і зокрема проекту по зміні інформаційної системи,є найскладнішою і менш за все піддається структуризації, і саметому навряд чи можна провести чіткий розподіл цієї стадії на фази, тимбільше, що вони можуть слідувати в різному порядку залежно відорганізації, від складності ситуації і від масштабу змін, включаючичасовий інтервал всього запланованого проекту.)
Як взагалі приймається рішення про проведення змін в інформаційнійсистемі? Причини зміни інформаційної системи описані в попередньомурозділі:
. технічні характеристики системи
. область діяльності організації
. функціональність системи
. моральне старіння системи
. політика організації щодо стандартизації процесів
. інтеграція різних областей діяльності організації
. престижність використання нової системи
На основі рекомендацій з боку співробітників організації або завласних міркувань (які також можна охарактеризувати однією зперерахованих вище причин) топ менеджмент приходить до висновку про те, щоіснуюча система не відповідає поточним потребам організації абоне буде їм відповідати в майбутньому. Приймається рішення про змінуінформаційної системи, причому детальна розробка необхідних змінздійснюється фахівцями компанії з усіх областей діяльності цієїкомпанії, які будуть порушені при зміні інформаційної системи.
Важливе зауваження: на даній стадії відбувається початкове плануваннязмін, головна мета якого полягає у визначенні основниххарактеристик майбутнього проекту (масштаб змін, області змін, типінформаційної системи (якщо відбувається зміна інформаційної системи),первинне визначення необхідної функціональності нової системи іт.д.).
На основі цього складається початковий приблизний план всього проекту,який проходить узгодження з топ менеджментом тих функцій, якихбезпосередньо торкнеться зміна інформаційної системи. Після того, яквідбулося узгодження, приблизні терміни намічені, набірфункціональності визначено, ресурси, які будуть прямо або побічнозадіяні в проекті, виділені, початкове планування проектузакінчується. Далі все детальні зміни будуть ставитися допланування в процесі здійснення проекту.

Розглянемо основні складові, які слід включити в початковий планпроекту:
. Опис об'єкта зміни (що необхідно змінити - систему, частина її функціональності і т.д.);
. Коротка рекомендація щодо необхідності зміни (причина зміни, переваги нової системи, опис цілей, яких потрібно досягти при завершенні проекту);
. Основні стадії проекту (див. нижче);
. Основна функціональність нової або зміненої системи (тобто список того, що увійде в проект) та строки проведення змін (якщо проект складається з декількох ступенів, результатом кожної з яких є зміна частини функціональності системи, то тут кожна ступінь повинен мати чітко поставлені терміни);
. Список учасників проекту, їх основних обов'язків і ролей (менеджер проекту, топ менеджмент, ресурси, учасники і т.д.);
. Бюджет проекту;
. Що не увійде до проекту (це необхідно для внесення ясності в очікування менеджерів робочих груп щодо можливостей системи);
. Які функціональні можливості системи потрібно вивчити в подальшому для потенційної установки надалі (список);
. Ризики (які чинники можуть перешкодити реалізації проекту в повному обсязі, в поставлені терміни з встановленим бюджетом);
. Критерії успішного виконання проекту
. Список необхідних умов, від яких залежить успішна реалізація проекту.

Планування в процесі здійснення проекту.
Наведена нижче схема показує узагальнений принцип планування проекту.
З однієї з деталей даної схеми є те, що планування в процесіпроекту являє собою безперервний процес, який триває дозавершення проекту. Це пов'язано зі складністю розробки ідеального плану,в якому будуть передбачені всі деталі і можливі зміни суб'єктивного
(пов'язаного з самим проектом) і об'єктивного (пов'язаного з зовнішнімиджерелами) характеру.

Рис. 3.1. Планування проекту по зміні інформаційної системи.

При найменших змінах (наприклад, коли виявляється, що системадозволяє запровадити новий процес з великою легкістю або коли хтось ізважливих учасників проекту з якої-небудь причини на час вибуває зпроекту) виникає необхідність коригування поставлених планів ічасу їх реалізації. Відповідно типи змін у планах можнапозиціонувати на матриці "терміни проекту - зміст проекту".

Рис. 3.2. "Терміни проекту - зміст проекту"

Досвід показує, що частіше за все змінюються терміни завершення проекту, причому восновному в бік збільшення. Це відбувається через те, що в успішнихорганізаціях при плануванні ставляться агресивні цілі для того, щобнадихнути співробітників на більш продуктивну роботу. Тому коливідбуваються зміни в процесі здійснення проекту (а вони як правиловідбуваються в кожному серйозному проекті) виникає необхідністьзалучення додаткових ресурсів, у тому числі і часу. Якщо крімчасу можливе додаткове використання такого ресурсу, як набірфункцій, то змінюється і зміст проекту. З іншого боку, додатковевикористання інших ресурсів (вартості і людей) зменшує необхідністьзбільшення часу, тобто скорочує строки виконання проекту.

Планування в процесі здійснення проекту відбувається на кожній стадіїпроекту на регулярній основі. Більш того, у міру просування проекту покожній стадії часто доцільно організовувати зборів основнихучасників проекту для визначення поточного стану справ та порівняння зпланом. Регулярність таких зборів залежить від тривалості проекту і йогомасштабу. Якщо між поточним станом справ і планом намічається різниця, тов першу чергу проводиться аналіз способів усунення відставання, а принеможливості усунути відставання змінюється план проекту, щоузгоджується з топ менеджментом на регулярних зібраннях (див. нижче).
При переході з однієї стадії на іншу складається детальний планреалізації нової стадії проекту відповідно до змін у планах, якщотакі є.

Стадії проекту по зміні інформаційної системи.
Тут автор запропонував би сконцентрувати увагу на такі зміни, якустановка нової системи при відчуженні старої (сюди в основному відносятьсятакі види зміни системи, як повна зміна системи, розширення функцій,а також іноді установка з нуля), тому що саме такі змінистановлять найбільший інтерес, є найбільш складними і вимагають більшуважного вивчення, тому що багато в чому пов'язані не тільки з технічнимирішеннями, але і з залученням людей їх різних функцій і з взаємовідносинамиусередині організації.
У різних організаціях існують різні підходи щодо планування змін.
Проте можна намітити загальні блоки, або частини, з яких складаєтьсяпроект по зміні інформаційної системи практично для будь-якоїорганізації (початком проекту в даному випадку автор запропонував би вважатимомент, коли початкове планування проекту завершено, необхідніузгодження зроблені і ресурси для участі у проекті виділені):
. Опис бізнес процесів
. Тренінги за новою системою (при необхідності)
. Тестування функціональності системи
. Необхідні доопрацювання
. Навчання користувачів функціональності системи
. Тестування системи користувачами
. Введення реальних даних
. Перехід на нову систему
Розглянемо більш детально кожну стадію.

Опис бізнес процесів.
Для того, щоб мати чітке уявлення про те, які конкретно процесибудуть піддаватися змінам і яким чином при зміні інформаційноїсистеми, потрібно мати чітке формальне опис існуючих процесів.
Детальність такого опису повинна бути на рівні концепції процесу іосновних його складових, а також входять і виходять ресурсів. Наприклад,якщо це процес обробки замовлень, то потрібно створити загальний описпроцесу (з чого починається, з чого складається і чим закінчується, в якечас відбувається яка стадія цього процесу, які параметри існують узамовлень, наприклад умови оплати, класи замовників, категорії послуг іпродуктів, з яких складів здійснюються відвантаження і т.д.). Приклад такоїсхеми наведений у Додатку 1 (Прийом замовлення). При описі бізнес процесівможе виявитися корисним створення схем, тому що вони наочно показуютьосновні складові процесу.
Опис бізнес процесів є не тільки базою, щодо якоїбуде змінюватися процес, але також опис процесів є певниммеханізмом оцінки можливих змін і критерієм, якому повиннавідповідати нова схема зміненого бізнес - процесу.
Опис бізнес - процесів здійснюється на самому початку проекту, арезультат цієї стадії - наявність свіжого збірника документації з процесіворганізації - є тією інформаційною базою, за допомогою якоїформується зміст змін в ході проекту.

Тренінги за новою системою (при необхідності).
Тренінги необхідні у випадку, коли безпосередні учасники проекту незнайомі з системою. Для того, щоб в учасників проекту сформувалосяпевне уявлення про нову систему, запрошують фахівців (цеможуть бути як зовнішні консультанти, аудитори або розробники системи, такі співробітники даної організації, наприклад з іншого філії, де системавже встановлена).
Слід зазначити, що немає необхідності в проходженні детального тренінгу,тобто такого тренінгу, який дасть повне уявлення про те, яксистема може працювати в інших організаціях. Це пояснюється унікальноюспецифікою бізнес - процесів кожної організації, обумовленої бізнестехнологіями, специфікою регіону або галузі. Учасники проекту можутьпрослухати курс з базової функціональності системи з поясненням тихпринципів налаштування тих параметрів (системних налаштувань), за допомогою якихможна створити необхідну інфраструктуру для здійснення бізнес --процесів. Фактично це означає, що основним завданням учасників проектунадалі буде моделювання бізнес-процесів організації, причому воноповинно бути засноване на принципі задоволення необхідних потреборганізації, а не використання існуючий можливостей системи.

Тестування функціональності системи.
Після проходження тренінгу учасники проекту починають тестувати систему.
Фактично це означає початок моделювання процесів в системі,змістовним стрижнем якого служить та документація, якастворювалася при описі бізнес - процесів. Відбувається перевіркаможливості системи обробляти в собі ту інформацію, яка циркулюєв організації. Це дуже важливий етап, тому що саме тут закладаєтьсяоснова того, що надалі буде називатися системою даної організації.
Всі подальші стадії будуть прямо залежати від цієї, а зміст цихстадій буде похідною від того, що буде закладено на даномурівні. Під час тестування системи створюється документація за описомфункціональних можливостей системи, а також починають формуватисяметодичні матеріали, що описують, як у системі виглядає той чи іншийпроцес; надалі така документація буде використовуватисякористувачами системи.
Також одним з ключових моментів автору бачиться в тому, що саме на данійстадії повинні відбутися все узгодження з майбутніми користувачами системиі їх менеджерами з прийнятності можливостей системи.

Необхідні доопрацювання.
У випадку, коли виявляється, що система не дозволяє здійснювати будь -небудь важливий процес (або в системі не існує необхідного прийнятногонабору звітності), формуються запити на розробку додатковоїфункціональності.
Розробка може здійснюватися як зовнішніми фахівцями, так івнутрішніми. Ця стадія відбувається як правило в паралелі з попередньоюі іноді навіть з подальшою (наприклад, коли доопрацювання не носятьістотного характеру і не можуть перешкодити навчанню користувачів іподальшого тестування системи).
На даній стадії може змінитися зміст проекту, причому як в бікскорочення частини системи, що впроваджується функціональності, так і в бік їїрозширення, яке багато в чому це також залежить від бюджету проекту.

Навчання користувачів функціональності системи.
Після того, як функціональність системи протестована, необхіднідоробки зроблені, наступає стадія, яка є прелюдією до шліфовцісістеми. Учасники проекту починають навчати користувачів роботі зсистемою. Це необхідно не тільки для того, щоб вони змогли якіснопротестувати систему і видати свої рекомендації, але також і для того,щоб вони звикли до системи і натренувались для подальшого ефективноговключення в роботу з новою системою (так званий "training on the job"),а потенційно можливий негативний настрій розчинився у вивченніможливостей системи і попередній роботі з нею.

Тестування системи користувачами.
Незважаючи на те, що система тестувалася учасниками проекту, як бидобре вони не розбиралися в процесах організації, у безпосередніхучасників робочих процесів (майбутніх користувачів системи) розвинененабагато більш детальне уявлення про ці процеси. Користувачі можутьзнати достатньо різних "підводних каменів", які з'ясовуються лишечерез певний час і які дуже складно врахувати в описі процесівлюдям, які не беруть участі в процесах на регулярній щоденній основі.
Це пояснюється ще й тим, що ситуація в бізнесі постійно змінюється,змінюються з нею і бізнес - процеси, причому такі зміни можуть бути якзначними, так і зовсім непомітними.
У ході тестування перевіряється якість системи, її повнота і готовність довпровадження. Тут багато чого залежить від учасників проекту. Під їхнімвідповідальність особливо має потрапити наступне:
. розробка набору сценаріїв тестів для користувачів:

. тести, що перевіряють функціональність системи;

. тести, що перевіряють взаємодію в системі між різними робочими групами, що прямо пов'язано з циркуляцією інформації по системі;розробка сценаріїв повинна проводитися учасниками проекту, тому що тільки вони мають так званий вид зверху на процеси, причому більш детальний, ніж менеджери робочих груп, а користувачі як правило не мають такого уявлення про процеси в цілому, будучи експертами в своїй області;
. складання розкладу (графіка) тестування - коли хто з користувачів має протестувати яку ділянку функціональності; тут особливу увагу слід приділити узгодженню даного розкладу з менеджерами і контролю за дисципліною проходження розкладом (тому що у користувачів є свої прямі обов'язки по роботі, вони для них як правило є первопріорітетнимі по відношенню до тестування нової системи, що є тим фактом, що вимагає додатково уваги з боку і учасників проекту, і менеджерів);
. вивчення думки користувачів про систему, обговорення її можливостей і детальний аналіз необхідності в додаткових доробках;
. проведення формальної атестації користувачів по знаннях нової системи і повідомлення результатів менеджерам як певний механізм присвоєння кваліфікації та підведення підсумків щодо готовності користувачів щодо роботи з системою.

Введення реальних даних.
Після того, як всі необхідні деталі по роботі системи узгоджені зкористувачами, система визнається готовою до