З чого починається проект для великої компанії? З пошуку вигідної пропозиції, вибору підрядника, вивчення ринку? Складання вимог? Вже тепліше. Як, через бажання почати правильно і самостійно, не потрапити у пастку. Як не закопуючись у численні деталі на старті, підібрати правильні рішення, мінімізувати ризики та адекватно все оцінити: бюджети, підрядників, свої сили.
Новини, анонси, майстер класи та ін. корисний контент для тих, кому важливо бути попереду та в курсі теми
Виступ на ERP-форумі:
Зміст:
Всім добрий день, мене звати Зосим Максим. Я керівник та засновник компанії TQM Systems. І сьогодні ми розпочнемо розділ, який стосується фази моделювання у корпоративних проектах. Я займаюся цим вже трохи більше 15 років, і тому щось у цьому розумію, і досі цим займаюся. У нас це не підтримка якоїсь методології. Саме так, як ми робимо у себе в компанії, і те, як ми працюємо з нашими замовниками – саме цю методологію я розповідатиму.
У корпоративних проектах фаза моделювання у нас ділиться на три етапи:
Усередині кожного з цих етапів є підрозділи. Дуже часто перше, і Володимир уже згадував у своїй презентації – не робити чогось. Так, дуже часто саме цим етапом нехтують компанії, починаючи корпоративний проект. Вони часто всередині сформулюють якісь вимоги до системи, і саме з цими вимогами і виходять на тендер. Чим це закінчується – ми трохи згодом подивимося.
Ми переконуємо, і саме працюємо, таким чином, щоб перед тим як взагалі розпочинати і проект, і написання технічного завдання та функціональних вимог робити експрес-обстеження.
У нього в нас входять наступні 9 розділів. Зупинитися я хочу на деяких з них, щоб дати якісь практичні кейси, які можна буде використовувати. Ми формалізуємо вимоги до верхнього рівня. Ми описуємо список бізнес-процесів, які в компанії потрібні для автоматизації. Ми не опускаємося до операцій цих бізнес-процесів, ми їх фіксуємо. І далі ми робимо підбір кількох систем, або однієї якоїсь платформи для автоматизації, щоб рухатися далі в моделюванні. Це дешевше, ніж одночасно моделювати для декількох систем. І ми робимо експертну оцінку – тобто те, що цікавить вас як замовника, і нас як виконавця – це, власне, терміни, бюджети, і скільки це все може зайняти часу.
Саме класичне – десь, на мою думку, на початку літа ми виклали… Хто не підписаний у нас на YouTube-каналі – заходимо і дивимося. Там детальне є відео про триточкову оцінку. Це частина методології PERT-аналізу, що оперує трьома сутностями. Він бере мінімальну можливість виконання того чи іншого процесу. Він бере середню – ту, яку відчуває експерт. І він бере максимальну. Тобто, у нас, по суті, є 3 оцінки. Не одна, а три.
Дуже часто з нас що запитують? «Дайте нам, власне, якесь одне значення».
Нічого краще, ніж ця формула, власне кажучи, не придумано. Так, це ми беремо мінімальне плюс 4 середніх, і плюс максимальне та ділимо на 6. І у нас виходить якийсь бюджет нашого проекту – те, наскільки ми змогли його деталізувати вниз.
Ми зіткнулися з тим, що даної методології недостатньо на ранніх стадіях проекту. Тому ми використовуємо ще 2 методології, ми запровадили їх цього року.
Наступна методологія, яку ми використовуємо – це функціональні точки. Ми, після того, як зафіксували всі вимоги, які потрібно автоматизувати в системі, ми їх рахуємо за функціональними точками, і ділимо їх відповідно на різні класи: прості, середні та складні.
І для кожної цієї функціональної точки ми повинні пройти якийсь ряд ітерацій, який потрібний для того, щоб це запрацювало ми маємо їх:
Чому поділ? Та тому, що для перших тут ще перемножено не просто години, а там ще й різні грейди. Тому що часто A, B, C ось ці роблять різні спеціалісти. Для рівня А досить там Junior, middle. Для рівня B – це лише middle. Для рівня С - це тільки senior, і там middle переходить у нього. Тому і тарифи, що перемножуються ось тут – вони, власне кажучи, відрізняються. Тобто те, що не можна у триточковій зробити. Це друга методологія, якою ми користуємось у нашій оцінці. І є третя методологія, вона дуже проста.
Люди, які попрацювали у певній галузі досить багато років – у них є таке якесь predict-бачення того, скільки займе та чи інша робота. Ось цим часто займаються або PM, або взагалі я, коли беру участь у процесі оцінки. Тобто це ти читаєш по діагоналі всі вимоги і розумієш, яка команда, і на який термін потрібна для виконання цього проекту. Саме це тут і закладено. Тобто ми вважаємо, яка команда для виконання певного проекту нам потрібна.
На сьогоднішній день, коли ми виконуємо експрес-обстеження, ми виконуємо всі три оцінки, всі три методології використовуємо. І зрозуміло, що всі ці три методології дають абсолютно різні цифри, і ми отримуємо таку картинку на виході. Тобто ми беремо всі ці три методології, і відкладаємо на осі Х і Y відповідно до місяця і там гроші якісь, і намагаємось…
Малюнок буває дуже різним. І відповідно чим вона збитіша – оцінювали це різні люди, і відповідно зрозуміло, що оцінка більш ймовірна. Буває дуже великий розліт, чи то в грошах, чи в термінах. Відповідно, найпростіший метод – за бісектрисами перетнути, і отримати точку, яка нам теж скаже про якусь оцінку.
Непрості є внутрішні нарада, коли ми доносимо, і збираємося всією командою, хто робив ці різні оцінки, тому що це різні люди, і запитуємо, чому та чи інша людина вважає, що це буде інша оцінка? Тому що, можливо, хтось щось пропустив. Тобто і ось, власне кажучи, ця методика перетину цих оцінок дає нам якусь там статичну інформацію про вартість. Це етап номер один.
А ось проблематика, власне, коли у нас цієї експрес-оцінки немає. Цей реальний тендер, буквально кілька тижнів давності, який проводила одна з компаній, він відкритий, і є на Prozorro, у якому ми брали участь. Як вам розліт у 65 разів? Це ось сформульовані вимоги. Всі компанії, тобто їх там ще, напевно, кілька - всі компанії отримали ті самі вимоги, один і той же список. І ось ми отримуємо. І увага питання, про яке теж згадував Володимир: «Ми ось це обиратимемо?» Тобто, розуміємо, що щось тут не так. Тобто ці цифри мають людину, яка оперує фінансами вводити в якийсь штопор та нерозуміння. Тобто щось тут не так - не може ось тут бути 15, а тут мільйон.
За свою діяльність ми зіткнулися… Але щось із цим треба робити. Найпростіше, власне кажучи, ми у кількох наших замовників зіткнулися з методологією, я не пам'ятаю, як вона називається, у неї теж є назва, з методологією оцінки відбору підрядників методом, власне кажучи, нанесення ось у цих точках перетину бюджету та відсікання зайвих по краях. Тобто ми не беремо найдорожчі, але ми й не беремо найдешевші – тобто ми беремо ось основну групу, власне кажучи, на розгляд, які до цієї групи потрапляють.
Для BAS ERP ось ця річ на сьогодні, на мою думку, є помилковою. Тому що не факт, що всі, хто потрапили тут, не помилилися. Можливо одна точка, яка знаходиться ось тут, правильніша. Тому що експертизи на сьогоднішній день 3+ проекти є всього у 5 компаній на ринку, у яких є там reference, і можна виходити, як це відбувається. Тому дуже акуратно із цими речами на стороні. Якщо ви проводите такий тендер, і ви отримали такі результати – квадрат може бути ось тут, наприклад. Тобто це ось те, що варто зараз пам'ятати та знати.
І ми, власне, попереджаємо замовника. Тобто для нас дуже часта ситуація, насправді коли ми вилітаємо з бюджету, і що цей документ є документом, з яким замовник виходить на тендер більш відкритий.
У нас є ось деякі замовники, яких я бачу і деякі партнери, які, власне, оцінювали.
Тобто цей документ вже дає більш вичерпне уявлення про те, яка складність і структура проекту. Ось відповідно ми з цим документом уже використовуємо інші інструменти.
Вийшли на тендер, визначились із підрядником, який вам цікавий, починаємо його робити.
Що ми робимо на наступних етапах? Ми вже формалізуємо всі вимоги до системи, які у нас є. Це етап, який дуже часто, пропускається. Тобто дуже часто замовник каже: «А давайте ми не описуватимемо процеси «as-is», давайте відразу будемо писати «to-be». Кожен другий замовник хоче відразу написати «to-be». І в цьому є помилка, бо якщо ви перебуваєте в якомусь стані, а коли ми пишемо «to-be», ми хочемо щось ще оптимізувати. Найчастіше ми розуміємо, що щось у наших процесах не таке. А навіть якщо розуміємо, і процеси будуть "to-be" практично такі самі, то в новій системі вони ведуться не так. Тобто «to-be» завжди від «as-is» відрізнятиметься.
І тут дуже важливий момент, що нам потрібно – це ці обидві схеми, для того щоб побудувати стратегію і так звану матрицю переходу. Ця матриця переходу є організаційною, бо буде ще одна – буде технічна. Яка це матриця може бути? Найпростіша – це у нас є два описи: є опис «Як є» і «Як буде». І бачимо, що тут трохи менше тексту, а тут трохи більше. Тобто щось тут відрізнятиметься. Не дуже очевидно, не дуже зрозуміло, але дуже просто. Дуже часто цього достатньо. Матриця переходу як таблиця. Є процеси «Як є», є «Як буде». І ми бачимо, що в таблиці вже трохи зрозуміліше, бо з'явилися якісь об'єкти, які відрізняються від існуючих. Ідемо трохи далі – є там якісь ролі у нас. Ми маємо таблиці, і ми розуміємо, що до певних ролей у нас додадуться певні процеси. І це нам дає можливість, власне кажучи, проаналізувати, що нам потрібно зробити.
У деяких випадках нам потрібно не просто нову систему поставити, нам потрібно організацію поміняти організаційно - нові посадові інструкції з'являться, нові взагалі ролі з'являться в компанії, які мають виконувати ту чи іншу дію. Тобто трохи покращилася картинка, так?
Для аналізу документообігу можна використовувати теж таку просту схемку. Тобто був ось такий процес там у 4 документи, став ось такий процес, ось він буде новою системою відображатись так.
Або можна ще трохи ускладнити і накласти і процес, і документообіг в одну табличку. Тобто у нас є документообіг, який був, і який буде, а є процес, який був, і який був ось тут, і який стане. Тобто ми бачимо, що тут є деякі блоки, які нам треба проаналізувати і скласти якийсь план дій – це і є матриця переходу: що ми робитимемо організаційно, для того, щоб цей процес запрацював ось так? Нової системи для цього замало, ще є організаційні питання.
Основною метою документа «Функціональні вимоги» є отримання gap-ів так званих. Тобто ми маємо промоделювати на системі, що у нас покривається типовим функціоналом, а що у нас не покрито типовим функціоналом та потребує доопрацювання. Саме цей список gap-ів у нас є основою для того, щоб далі виконувати технічне завдання. Там теж чимало різноманітних елементів. Я зупинюся на деяких, які найболючіші насправді. Хоча від проекту до проекту це можуть бути різні речі: у когось дуже болюча річ – це НСІ та перенесення цих даних, у когось зовсім інші.
Але дуже часто саме інтеграції – це така велика біль будь-якого проекту. Тому що на сьогоднішній день дуже багато в компаніях IT-інфраструктура є дуже розширеним таким спектром різних систем: сайти, облікова система, бухгалтерська система, якісь портали клієнтів, CRM-системи. Це все може бути рознесене за різними системами. І коли ви намагаєтесь, шматок вирвати і вставити на його місце новий шматок, в якому відрізняється процес, то це створює відмінність загалом у структурі самих інтеграцій.
Тобто нам потрібно в цей момент побудувати якусь схему, мати якісь шини даних або там якісь мати старі системи. Тобто має бути стратегія, як ми будемо тими даними, які ми мали, оперувати в новій системі. Тобто ми їх або кудись у якийсь куб, або ми їх кудись у якусь шину, або ми робимо доступ до старих систем, або ми їх повертаємо та використовуємо просто як доступ до старої системи. У кожного проекту це буде по-різному здійснюватись.
А ось у нас з'являється ще стратегія матриця переходу технічна, бо теж питання не з найпростіших насправді. Тобто тут ми вже оперуємо логічними поняттями – де яка система знаходиться, і яку функцію на якому рівні вона виконує? Тобто на рівні якого сервера, яка система стоїть, з чим він взаємодіє, і так далі. І ця структура, зокрема, відрізнятиметься. Тому що, якщо в процесі проекту у вас змінюється бізнес-логіка зміни доступу до даних, то ось ця бізнес логіка зміниться. І перейти від однієї технічної інфраструктури до іншої іноді дуже непросто. Особливо коли нам потрібні там високонавантажені системи, коли ми розглядаємо, там є там висока вимога до обробки даних та швидкості даних. Це не завжди про платформу BAF, або це не завжди про поточну конфігурацію. Іноді це робиться з нуля, іноді це робиться чистими мовами, іноді для цього взагалі використовуються якісь зовнішні сервіси.
Повертаємося ще до цієї методології. Ось коли у нас сьогодні вже є технічне завдання – дуже добре працює триточкова оцінка. Ось у цьому інструменті, коли ми з верхньорівневим, з дуже високоабстрактним завданням опустилися до рівня: «Треба реалізувати довідник такий-то, документ такий-то, друковану форму таку-то», – то у нас ці цифри стають дуже зрозумілі, і нам дуже легко ними оперувати. Тому вже тут ви можете використовувати цей інструмент. У даній ситуації ми на технічному завданні вже не користуємося іншими інструментами, ми використовуємо тільки триточкову оцінку.
Які рекомендації щодо старту проекту, які вже можна винести після там майже десятка різних стадій? Дуже часто, загалом, це було зрозуміло, коли був продукт новий, і він не мав певних курсів, то проект починали: замовник як такий не розуміє ні архітектури, ні логіки роботи нового рішення. Це дуже часто розтягує процес прийняття рішень, коли команду замовника необхідно навчати там і таке інше. Ми рекомендуємо до початку проекту вашу робочу групу відправити повчитися кудись.
Ось САБ проводить дуже багато різних тренінгів, як за певними підсистемами, якщо ви хочете запускати певну підсистему, так і за загальною концепцією системи. Там є окремо BAS ERP, окремо BAS УХ. Є окремі тренінги, які слід прослухати. Тобто вони допоможуть вам спілкуватися з аналітиками, які прийдуть описувати процеси однією мовою. Тобто вам буде простіше, як мінімум, розуміти цю документацію і сам продукт.
По-друге – це, власне кажучи, все те, що я розповідав, якщо ви помітили. Тобто я розповідав про якісь поверхові деякі речі. Насправді кожен із тих пунктів: яким чином описувати процеси, як моделювати, як у технічному завданні описувати – тобто, що має бути доопрацьовано, щодо інтеграції тощо. Є окремий тренінг з обстеження та моделювання у корпоративних проектах. Він іде один день, веду його я зі своїм колегою. Ми один уже робили у жовтні, і наступний має бути, там, на мою думку, змінилося – там не 3 березня, а 2 березня. Це буквально вчора змінилося. Загалом, слідкуйте за новинами на сайті САБ – там буде оголошено місце та дата, наступного тренінгу.
Це дозволить вам, мало того що, якщо у вас вже запущений проект, і вам дозволить простіше читати ці документи, які вам надаються, це дозволить на виході з цього тренінгу, ми прагнемо до того, щоб ваша внутрішня команда вона могла зробити це самостійно. Тобто, щоб ви змогли пройти всі три стадії, про які я говорив. Тобто від експрес-обстеження до написання функціональних вимог та моделювання ми розповідаємо нотацію BPMN у цьому тренінгу. Їх є ще кілька. Можливо, у вас вже в інших нотаціях опис існує. Тому там, на слайді, я вказав, що «as-is» – вони можуть бути описані у вашій нотації. Тому що іноді ми стикаємося з тим, що у компанії вже написані процеси «to-be», і ми здебільшого розповідаємо, що 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
