Автоматизуючи хаос, отримаємо автоматизований хаос, а якщо конкретно, то перш ніж приступати до доопрацювання програмного продукту, необхідно проаналізувати всі процеси, що протікають в компанії, інакше процес доопрацювання може перетворитися на нескінченне доопрацювання доопрацьованого.
Етап призначений для збору і аналізу докладної інформації про підприємство Замовника з метою проектування системи. В рамках даного етапу:
Може проводитися як одним етапом, так і окремими блоками, тобто спочатку описуємо процеси логістики, потім продажів, потім виробництва.
Для формалізації бізнес-процесів наші фахівці використовують методику, що базується на BPMN.
Даний етап робіт дозволяє знайти вузькі місця в управлінні бізнес-процесами компанії, описати документообіг компанії і вивчити регламенти роботи співробітників. Даний етап повністю підготує структуровану інформацію для виконання етапу консалтингу в компанії.
Роботи призначені для опису ваших бізнес-процесів, розробки Функціональних вимог, Технічного завдання і Контрольних прикладів.
Вам потрібно автоматизувати бізнес. З чого почати? Як це зробити правильно, щоб нічого не упустити і в результаті отримати повноцінний ІТ-інструмент для розвитку бізнесу? Адже часу, грошей та інших ресурсів у автоматизацію доведеться вкласти немало.
У відео ми обговорюємо ключові питання підготовки до впровадження, тому що саме від етапу підготовки і моделювання залежить безпосередньо весь подальший процес розробки і впровадження.
Впровадженням систем ми займаємося вже 15 років, і за цей час провели чимало різноманітних проєктів.
Використовуючи різні методології, підбираючи потрібні інструменти, на сьогодні ми сформували свій практичний підхід. Саме так ми робимо у себе в компанії і працюємо з нашими замовниками. Це найбільш раціональний підхід з найбільшою точністю і ефективністю.
У корпоративних проєктах фаза моделювання у нас ділиться на три етапи:
Часто компанії нехтують експрес-обстеженням, вважаючи, що для проведення тендера досить самостійно сформувати якийсь список вимог до системи. Це призводить до того, що пропозиції на тендері дуже сильно дивують замовника, і вибрати підрядника стає дуже важко.
Ми обґрунтовуємо клієнту необхідність експрес-обстеження і ще до початку проєкту його проводимо.
Все про експрес-обстеження докладно описано тут >>>
З 9 розділів розглянемо тут ті, що готують інформацію для опису бізнес-процесів:
Ми формалізуємо вимоги верхнього рівня, фіксуємо список бізнес-процесів компанії, які потребують автоматизації. Описуємо їх укрупнено, не розшифровуючи до операцій.
На підставі списку бізнес-процесів проводимо підбір однієї або декількох базових систем.
Далі моделюємо для обраних систем - це дешевше, ніж моделювати для декількох варіантів, а вже потім робити вибір.
І далі ми можемо скласти експертну оцінку, тому що саме це цікавить замовника - ціна проєкту і терміни виконання.
Як проводити оцінку - про це можна подивитися відео на нашому каналі.
PERT: Project Evaluation and Review Technique - техніка оцінки та аналізу
За методологією оцінка виставляється на підставі 3-х позицій:
І для того, щоб отримати єдину, найбільш зважену ціну, яка і цікавить замовника, є методика її розрахунку.
Детально в статті та відео: Триточкова оцінка >>>
Оцінка дасть попереднє, максимально наближене значення бюджету, деталізоване настільки, наскільки глибоко ми розписали завдання.
Але яким би науковим і перевіреним не був метод триточкової оцінки, на практиці ми зіткнулися з тим, що її недостатньо на дуже ранніх стадіях проєкту. Тому ми використовуємо ще 2 методології, ми ввели їх цього року.
Зафіксовані вимоги, які потрібно автоматизувати в системі, потрібно порахувати за функціональними точками і поділити їх відповідно на різні класи: прості, середні і складні.
Для кожної функціональної точки визначається ряд ітерацій, які потрібно пройти, для того щоб процес запрацював - це, наприклад:
Крім оцінки кожної точки в годинах, виставляється ще одна оцінка - грейди, тому що роботи роблять фахівці різного рівня кваліфікації.
Тарифи оплати праці відповідних фахівців відрізняються, тому така оцінка значно уточнює бюджет. Цього не можна зробити в триточковій оцінці.
Як додаткову методологію ми використовуємо експертизу. Вона дуже проста з точки зору кількості дій, але вимагає наявності висококваліфікованого фахівця.
У людей, які попрацювали в якійсь галузі досить велику кількість років, є predict-бачення того, скільки займе та чи інша робота. Цим займаються PM.
Досвідчений фахівець, читаючи всі вимоги, розуміє, яка команда і на який термін потрібна для виконання проєкту. Це закладається в оцінку.
На сьогоднішній день, коли ми виконуємо експрес-обстеження, ми виконуємо всі три оцінки, за трьома перерахованим вище методологіями.
І, звичайно, всі оцінки дають різні цифри. Далі для цих оцінок ми будуємо сітку, на осі Х і Y відкладаємо час і вартість. Чим ближче різні оцінки, тим вони більш вірогідні.
На практиці розліт у грошах або термінах буває дуже великим. І найпростіший метод отримати усереднену оцінку - знайти перетин бісектрис.
За результатами оцінок ми обов'язково проводимо внутрішню нараду. Її не можна назвати простою. Вся команда захищає свої оцінки. Ми з'ясовуємо, чому та чи інша людина виставила саме таку оцінку. Так ми переконуємося, що ніхто нічого не пропустив.
За всіма уточненнями розраховуємо усереднену оцінку. Вона і береться за основу розрахунку бюджету, що надається клієнтові.
Так багато уваги потрібно приділити оцінці! А це ж лише попередньо, і навіть ще не прийняте остаточне рішення про те, чи відбудеться взагалі проєкт. І клієнти часто вважають, що не так все це важливо для вибору підрядника.
І ось приклад з практики: що буває, коли експрес-оцінки немає. Це реальний недавній тендер, буквально декількох тижнів давності, який проводила одна з компаній. Він відкритий і є на ProZorro, і ми в ньому брали участь. 
Брало участь багато компаній, всі вони отримали один і той самий список вимог.
Розліт оцінок із сформульованих замовником вимог склав шістдесят п'ять разів!
Людину, яка оперує фінансами, ці цифри повинні вводити в ступор і нерозуміння: щось тут не так. Виходячи зі здорового розуміння, не може один підрядник зробити це за 15К, а інший за це ж просити 1 мільйон.
Отримавши різноманітні оцінки тендера, щоб якось системно підійти до вибору, замовник теж застосовує методологію відбору підрядників, наносячи на сітку координат бюджети і відсікаючи по краях: відсікаються найдорожчі і найдешевші, і до розгляду приймається основна група найбільш щільно розташованих оцінок.
Для об'ємних і складних проєктів - наприклад, впровадження BAS ERP - вибирати підрядника за попередньою ціною без обстеження на сьогоднішній день помилково і ризиковано. Тому що середня ціна, яка позначається на графіку, може бути взята підрядниками з досвіду ведення проєктів з іншими системами, але схожими масштабами підприємства. І це взагалі не про BAS ERP.
Тому що експертизи на сьогоднішній день є всього у 5 компаній на ринку, у кого 3 і більше проєктів за цією системою, і вони вже знають, як це відбувається, і можуть оцінювати.
Можливо, одна точка з високою ціною для проєкту із BAS ERP більш правильна.
Коли ми робимо експрес-обстеження, ми попереджаємо замовника, що наша оцінка може виходити за рамки середнього бюджету, який запропонують на тендері. Але за результатами обстеження клієнт отримує документ з вичерпною інформацією для виходу на відкритий тендер.
Тобто цей документ дає більш повне уявлення про те, яка складність і структура проєкту, і підвищує достовірність оцінки усіма учасниками тендеру.
На наступних етапах ми формалізуємо всі наявні вимоги до системи.
Дуже часто замовник намагається пропустити опис поточного стану процесів as-is і скоріше приступити до опису бажаної картини to-be. Але це помилка.
Коли ми описуємо to-be (як буде), потрібно розуміти, що оптимізувати і змінювати, і це можна зробити, коли ми розібрали і розписали процеси (як працює зараз as-is). Тоді можна визначити, яку частину процесу змінювати. Крім того, в новій системі можуть бути свої правила ведення процесів. Тобто to-be завжди буде відрізнятися від as-is.
І тут дуже важливий момент: потрібні обидві схеми - as-is і to-be - для того, щоб побудувати стратегію, і організаційну матрицю переходу, і технічну.
Яка це матриця може бути? Найпростіша - коли у нас є два описи: як є і як буде, і складається перелік всіх відмінностей. Цей опис буде слабо структурованим, але дуже простим, і часто цього достатньо.
Складніша матриця переходу складається як таблиця, і містить опис процесів як є і як буде, а далі виділяються об'єкти, які в майбутньої моделі будуть відрізнятися від поточної. Доповнюється таблиця процесами, які можна створювати, застосовувати до об'єктів або трансформувати.
На наступному кроці в таку таблицю додаються ролі, і це дозволяє зіставити певні ролі з процесами, проаналізувати їх і скласти план подальших дій за проєктом.
У деяких випадках нам потрібно не просто нову систему поставити, потрібно змінити компанію організаційно: з'являться нові ролі, нові завдання і посадові інструкції, багато з них змінюються і доповнюються. І тільки за цих умов впровадження системи дасть поліпшення.
За такою ж схемою (було-буде) аналізується і документообіг, наприклад, "був такий процес в 4 документа, а став ось такий процес і він буде в новій системі відображатися так...".
Більш складний аналіз вийде, якщо поєднати зміну документообігу зі зміною процесів. Для цього складається таблиця, де по блоках розписується, які потрібні трансформації, щоб as-is перетворити в to-be. За підсумком складається план дій - це і є матриця переходу, яка описує, що потрібно робити організаційно для того, щоб цей процес запрацював, як задумано. Нової системи для цього недостатньо, ще є організаційні перетворення.
Основною метою документа Функціональні вимоги є отримання ГЕПів (Gap - зазор - визначається як незаповнений простір або інтервал.). Ми повинні промоделювати на системі, що у нас покривається типовим функціоналом, а що не покрите і потребує доопрацювання. Саме цей список ГЕПів є основою для написання технічного завдання.
Тут вже велика різноманітність елементів, серед них є дуже болючі. І від проєкту до проєкту вони різні: для когось дуже болюче питання НДІ і перенесення цих даних, для когось зовсім інше.
Дуже часто саме інтеграції - це великий "головний біль" будь-якого проєкту, тому що на сьогоднішній день дуже багато у компаній ІТ-інфраструктури, вона являє собою широкий спектр всіляких систем: облікова система, бухгалтерська система, сайти, якісь портали клієнтів, CRM-системи, платіжні системи, месенджери. Все рознесено по різних системах, і, приступаючи до нового впровадження, один шматок процесів потрібно замінити на інший, який відрізняється, і це тягне зміни в структурі самих інтеграцій. І потрібно попередньо до цього моменту побудувати схему змін, побудувати шини даних. Можливо, потрібно використовувати старі системи в частині передачі даних. Але однозначно необхідна стратегія, як ми будемо оперувати тими даними, які у нас були, в новій системі. Чи можна використовувати куб даних, шину даних, стару систему або доступ до частини функцій?
У кожного проєкту план інтеграцій буде здійснюватися по-різному.
Для побудови стратегії потрібна ще технічна матриця переходу, і її побудова теж непросте питання.
У технічній матриці переходу ми оперуємо логічними поняттями: де яка система знаходиться, і яку функцію на якому рівні вона виконує, тобто на рівні якого сервера яка система стоїть, з чим він взаємодіє і т.д. І цю структуру в рамках проєкту потрібно буде змінювати, тому що, якщо в процесі проєкту у вас змінюється бізнес-логіка і потрібні зміни доступу до даних, перейти від однієї технічної інфраструктури до іншої іноді буває дуже непросто.
Особливо очевидно це для високонавантажених систем. Для них, крім інших, ще є вимоги високої швидкості обробки даних.
Такі рішення не завжди будуються на платформі BAF або якійсь іншій платформі.
Іноді базова конфігурація ПО взагалі не використовується, і система розробляється з нуля. Іноді це робиться на чистих мовах, іноді для цього взагалі використовуються якісь зовнішні сервіси.
Варіантів рішень багато, і підбираються вони індивідуально безпосередньо під вимоги бізнесу.
Коли вже є технічне завдання, дуже добре працює триточкова оцінка. Коли ми з верхнього рівня, від дуже високоабстрактного завдання, опустилися до рівня завдань по типу "треба реалізувати довідник Х, документ Y, друковану форму Z", тоді оцінка трудомісткості і розрахунок вартості стають зрозумілими. Тому для оцінки за технічним завданням ми вже не користуємося іншими інструментами, і використовуємо тільки триточкову оцінку.
Які рекомендації можемо дати для старту проєкту з впровадження системи BAS ERP? Їх ми сформували після більш ніж десяти різних проєктів.
Спочатку, коли продукт був новий, ще не було навчальних курсів, і у замовника не було можливості ознайомитися з архітектурою і логікою роботи нового програмного комплексу. Це значно затягує процес прийняття рішень, тому що команду замовника необхідно спочатку вчити.
Ми рекомендуємо до початку проєкту вашу робочу групу відправити на навчання.
САБ проводить дуже багато різних тренінгів, як із загальної концепції системи, так і з певних підсистем, якщо, наприклад, ви хочете запускати певну підсистему. Є окремі програми навчання із BAS ERP, і з BAS УХ, і перед стартом впровадження їх потрібно прослухати. Таке навчання допомагає спілкуватися однією мовою з аналітиками, які будуть описувати процеси. Стане набагато зрозумілішою підготована документація і рішення, які виходять із архітектури самого продукту. І це значно економить час, і, відповідно, окупається, і, звичайно, покращує якість прийнятих рішень за проєктом, оскільки ґрунтується на знанні.
Для того, щоб аналітик міг повноцінно пройти передпроєктний етап, йому, крім знайомства з системою, знадобляться ще знання: яким чином описувати процеси, як моделювати, як в технічному завданні описувати, що має бути доопрацьовано, як інтегровано і багато ще.
Ми проводимо окремий тренінг з обстеження та моделювання в корпоративних проєктах, він триває один день .
Проходження такого тренінгу, якщо у вас вже запущений проєкт, дозволить простіше розбирати документи, які вам надаються. А в цілому тренінг ми побудували так, щоб після його проходження ваша внутрішня команда могла зробити це самостійно - пройти всі три стадії, від експрес-обстеження до написання функціональних вимог і моделювання.
На тренінгу ми розповідаємо про нотації BPMN. Нотацій є ще кілька, і можливе використання інших. Процеси as-is можуть бути описані у вашій нотації.
Ми вибираємо BPMN, тому що вона легко читається і є найпростішою для розуміння системою нотації.
На підставі отриманих знань вже можна складати технічне завдання - і це вже документ для більш точної оцінки проєкту.
Це короткий огляд курсу.
Питання: "Чи реально за один день всьому навчитися?"
Насправді в реальності тренінг розрахований дати базис, основний кістяк практичних знань, для того щоб ви знали, куди далі копати. Зрозуміло, що сам BPMN можна вчити три місяці. І глибина вашого освоєння знань залежить вже від кількості витраченого вами часу, зусиль і поставлених цілей. Але розуміння, яким чином це робити, у вас з'явиться.
Звичайно, потім потрібно буде придбати ще чотири книги і розбиратися з кожним питанням всередині окремо, і опрацьовувати кожен з них на практиці вже безпосередньо в вашому проєкті.
Відео про ключові моменти впровадження систем автоматизації на каналі TQM systems: кейси, приклади впроваджень, методики роботи, параметри вибору, нові розробки і можливості.
SaaS сервіси
Програми 1С:Підприємство
CRM
ERP
Node.JS, .NET
1С:Підприємство
API, IPasS
Разработка Web Apps
1С:Підприємство Автоматизація
Аудит IT проектів
Інтеграція 1С:Підприємство
Отримуйте наші інформаційні матеріали:
Працюємо на IT-ринку з 2008 року.
Наша місія - спростити управління даними.
Copyright © 2008-2024 TQMsystems. Всі права захищені. Privacy Policy | Terms of Service
