Чому знадобилося впровадження нового продукту? Як підійшли до вибору, чим був обумовлений? З чим зіткнулися на першому етапі впровадження, які винесли уроки? У чому різниця між новим продуктом BAS ERP і вже наявним досвідом впроваджень? Чому не вийшло просто встановити з коробки? Що насправді потрібно бізнесу від системи автоматизації? У чому різниця між великими компаніями і невеликим бізнесом? Які методології впровадження використовуються?
Про це та ще багато важливих деталей читайте в нашій статті і дивіться відео.
Формат CIO-Jazz - це майданчик для спілкування і обміну досвідом від «Співтовариства ІТ директорів України». Тут обговорюються конкретні питання підвищення ефективності використання ІТ для розвитку управління бізнесом.
Доповідь ведуть:
Євген Осьмак, Head of corporate IT, Роман Маслюківський, компанія "Zeppelin".
Максим Зосим, підрядник за проектом, компанія "TQM Systems".
"У компанії не стояло питання вибору продукту автоматизації, буде це BAS ERP або якийсь інший, - каже Роман.
Оскільки ті виклики, які у нас були, інфраструктура і архітектура систем, вимагали продукт такого класу, і один з кращих заявлених такого рівня - це BAS ERP.Зараз відбувається активна фаза виконання проекту, тому остаточних висновків поки немає, але вже є ряд уроків, які винесли на поточний момент ".
Над проектом працюють 2 паралельні команди розробки:
Внутрішній центр компетенцій, який займається впровадженням, в тому числі і продуктів 1С: Підприємство, включає аналітиків, проектних менеджерів і людей, до них прирівняних, розробників;
зовнішній партнер - це компанія TQM systems: працює 14 чоловік, це інженери, безпосередньо аналітики і розробники.
Такий тандем працює над впровадженням цієї системи.
Сумарна кількість інженерів у проекті з обох сторін - близько 30. Кількість людей, що беруть участь в проекті разом з експертами, - близько 50.
Яка система використовувалася раніше
У компанії вже була ERP-система, і спочатку проект розглядався як апгрейд існуючої, вже вибудованої бізнес-логіки процесів за допомогою BAS ERP. Але на ділі виявилося, що для BAS ERP впровадження потрібно починати з нуля. З цієї причини змінили партнера і відійшли від поняття апгрейду, і з новим партнером почали практично заново.
"Попередня система була встановлена в 2010 році, - розповідає Євген. - Впровадження пройшло гладко і безшовно, і система відпрацювала 8 років на високому рівні".
На певному етапі стало зрозуміло, що існуюча система вже не відповідає реальній моделі бізнесу - компанія змінилася, і розрив між ними покривається за рахунок застосування додаткових тимчасових рішень, і таких рішень стає все більше.
Архітектурні рішення, які 8 років тому були вдалими, тепер стали обмежуючим фактором для подальшого розвитку компанії.
Керівництво компанії дуже добре розуміло потребу в змінах, оскільки з ІТ велася постійне тісне опрацювання питань, і переконувати в необхідності переходу на нову систему не довелося.
Серед заявлених функцій і технологій BAS ERP були ті, які могли принести реальну вигоду бізнесу відразу за результатами впровадження. Впевненість у правильності прийнятого рішення підкріпилася ще одним невеликим проектом: впровадженням мобільного клієнта для частини функціоналу, що ефективно оптимізував один з бізнес-процесів. Це дозволило відчути реальні вигоди від зміни в одній тільки точці. І в подальшому це значно підтримало ІТ-ініціативу.
Раніше УВП - вважався найважчим і найскладнішим продуктом, і все ж його архітектуру (об'єкти, зв'язки, документи) можна було охопити розумінням одного фахівця.
BAS ERP – набагато складніший продукт, на його повне розуміння необхідно більше 5-6 людей. А краще - по фахівцю на кожен модуль. Він настільки ускладнився з точки зору взаємодії з іншими модулями, роботи, параметрів і залежностей, що для однієї тільки синхронізації з тестовою базою потрібно налаштувати 219 функціональних галочок. Вони включають або відключають цілі області функціоналу, і залежно від налаштувань система буде поводити себе інакше та іншим чином візуально відображати інтерфейс.
"Обумовлена складністю системи BAS ERP структура проектних команд сьогодні дуже змінилася", - говорить Максим Зосим, директор "TQM Systems".
Якщо раніше можна було покласти впровадження УТП або УВП на 10 фахівців і ставити питання: "ми самі впроваджуємо або передаємо процес на аутсорсинг?", то зараз з'явився сполучник "і": "ми і самі впроваджуємо, і передаємо частину процесу на аутсорсинг".
Яка методологія використовується в проекті
У проекті задіяно кілька методологій, тому що є різні вимоги до документів. Внутрішні документи можуть бути на 20 сторінок, а зовнішні за схожим функціоналом - на 90 сторінок. Це пояснюється тим, що потрібно створити рівень розуміння всіх нюансів із замовником і переконатися, що ваші розуміння збігаються.
План-графік проекту - це класичний Waterflall - моделювання, розробки і т.д., а всередині кожного з пунктів застосовується класичний Agile: ітерації, планування аж до тижневих спринтів. Кожна функціональна одиниця проходить по Канбану. Виходить мікс.
Важливий момент: для різного розміру компаній однаковими термінами можуть називатися зовсім різні речі.
Наприклад, двом різним замовникам потрібно бюджетування або казначейство:
Тому потрібно враховувати різницю в значенні термінів залежно від масштабів.
Це питання зрілості компанії.
Є компанії, готові моделювати процеси "as is", "to be" і матрицю переходу. Таким чином, ми це робимо і переходимо, тому що такі трансформації стосуються не тільки автоматизації, а зачіпають організаційні та процесні зміни, і навіть підштовхують до реінжинірингу оргструктури.
Але є компанії, які не розуміють, навіщо ці 3 формати. Тоді можна пропонувати робити згідно з новим функціоналом, і вони готові міняти свої бізнес-процеси, тому що вони не розуміють їх зараз, ніколи їх не моделювали, і правила в системі стають їх "to be".
Незважаючи на величезний функціонал системи і гнучкість налаштувань, за проектом Zeppelin вже витрачено більше 10 тисяч годин, і надалі планується ще не менша кількість.
На практиці можна застосовувати 2 підходи:
Але в цілому час на налаштування обов'язково знадобиться. Навіть щоб просто визначити, які з "галочок"-параметрів повинні бути включені для вашої компанії, а які - ні, потрібно досить багато часу.
Для розуміння обсягу робіт на прикладі Zeppelin можна пояснити, що компанія тісно інтегрована з її основним вендором в Німеччині. Інтеграція зачіпає не тільки обмін даними, але й більшість процесів, вибудовуючи ніби єдиний потік створення цінностей. В іншу сторону компанія теж інтегрована з великими замовниками - це українські гірничопромислові комбінати. Загальні процеси тісно пов'язані з їх внутрішніми ERP-системами.
Ці фактори створили цілий ряд унікальних функціональностей, яких немає в будь-якій із систем автоматизації.
Раніше структура трудовитрат за проектом на базі 1С: Підприємство розподілялася як 25/75%. 25% - це аналіз, моделювання, взаємодія аналітика з користувачем, і 75% - це програмування і все, що з цим пов'язано: тестування, адаптація, перенесення даних і інше. Зараз етап моделювання займає 60% на 40% програмування. І за проектом Zeppelin тепер основний обсяг робіт - це процес моделювання і прийняття того, як працювати в системі.
Зараз часто потрібно витратити 100 годин на опис завдання, щоб потім витратити набагато менше, скажімо, 20 годин, і все акуратно запрограмувати.
Євген Осьмак, посилаючись на теорему Геделя, пояснює: у нетривіальної системи може бути 3 властивості: універсальність - покриває все навколо, повнота - покриває всі бізнес-процеси вглиб, і внутрішня логічна несуперечливість. Це пояснює, що в реальності задовольняються лише 2 властивості, і одною з них буде обов'язково несуперечливість.
З точки зору вендора, створюється або рішення під певну галузь (чим вужче, тим краще, - тоді доведеться не виходити за її рамки і працювати тільки з цією окремою вузькою галуззю), або потрібно робити систему універсальну, але при цьому неповну (вона підходить кожному , але на 60%, а решта 40% функцій потрібно вносити самостійно).
І наявність великої кількості налаштувань в BAS ERP говорить про те, що вендор має намір максимально охопити всі галузі і створити універсальну систему, але при цьому автоматично за рахунок повноти. В системі є всілякі процеси, але глибина їх опрацювання невелика і потребує доопрацювання під потреби індивідуального бізнесу.
Причому глибина опрацювання окремих процесів в самій системі з коробки різна, і вона залежить від тієї ж методологічної команди розробки самого вендора, якщо провідні фахівці мають досвід роботи на виробництві, але при цьому слабо розбираються в маркетингу, продажах або HR.
І така ж картина буде у будь-якого вендора, чи то є SAP, 1C:Підприємство чи Microsoft, - всі вони хочуть універсальності.
Просте рішення, яке підходить всім і на всі 100%, - це ситуація, яка не існує в природі..
Опис проекту Zeppelin (Цеппелін Україна) - впровадження BAS ERP дивіться на нашому сайті >>>
Тетяна Коваленко, викладач бізнес-школи "КРОК":
Діджитал-трансформація починається з трансформації кожного з нас. Не когось, не якогось відділу, не керівника, не менеджера, не партнера, не клієнта - з нас. На своєму прикладі пробуємо, спостерігаємо і тестуємо.
Олександр Бобровський, директор напрямку "Автоматизація бізнесу" компанії «Софтком»:
Вже час діджиталізації в Україні настав, можна сказати. І держава давно вже перестала приймати паперову звітність і перейшла на електронну. Час переходити вже і в наших взаєминах теж на безпаперовий документообіг.
Вікторія Ільченко, бізнес-аналітик, "Всеукраїнська спілка автоматізаторів бізнесу":
Серед тих рішень, які нам допомагають зростати, - це випущена лінійка інноваційних продуктів BAS. Це BAS ERP, про який ми зараз будемо багато говорити, і це BAS Управління холдингом - довго була бета, зараз, нарешті, вже вийшов реліз, маємо вже перші впровадження.
Юлія Ільчук, керівник відділу розробки "TQM Systems":
І продовжить тему лінійки BAS тема «Безшовна інтеграція BAS ERP і BAS документообіг». Для чого це потрібно? Така реалізація дозволяє нам відмовитися від запуску кількох баз на одній машині робочій кінцевого користувача. Дозволяє скоротити часові витрати на запуск певних процесів і погодження в двох базах, дозволяє скоротити витрати на папір. Скажімо так, ми не бігаємо з папірцями в такій реалізації, інтеграції. Власне, у нас обидві бази. Вони інтегровані, синхронізовані з точки зору необхідної нормативно-довідкової інформації, так як в ході інтеграції у нас відбувається обмін і наповнення баз.
Євген Осьмак, Head of corporate IT "Zeppelin":
Доброго дня. Мене звуть Євген, я працюю в компанії з ... там все написано. І оскільки час мого виступу закінчився за регламентом, я вам тільки одне питання задам: скажіть, а кому реально цікаво щось про BAS ERP? О, (багато рук), добре. Тоді я, звичайно, передам... Я ось з Романом Маслюківським, він тут сидить, ми працюємо в одній компанії. І оскільки Роман відповідає за впровадження BAS ERP у нас в компанії, а я йому намагаюся активно не заважати, через це слово потрапляє до нього.
Роман Маслюківський, Head of 1C Applications Group, “Zeppelin”:
Доброго дня. Як сказав мій колега, він мене всебічно представив: хто, що, чим займається. Разом з тим, я б хотів уточнити питання: крім того, що вам цікаво про BAS ERP, мені цікаво, хто знаходиться на роздоріжжі, чи впроваджувати BAS ERP або перед вибором BAS ERP, крім інтересу?
2-3 людини приблизно. Напевно, менше.
У нас не стояло питання - впроваджувати BAS ERP або якийсь інший (програмний продукт). У нас це питання було вирішене не на 100%, але близько до цього. Тому що та інфраструктура, та архітектура систем і ті виклики майбутнього, які у нас були, вони просто нам говорили, що нам потрібен продукт цього класу, і продукт того класу, одного із заявлених, найкращого рівня. Це був BAS ERP.
Вам сьогодні колеги, які професійно займаються продажем цього рішення, вони вам про це розповіли, і не будемо про це багато говорити.
Разом з тим, у нас тут дискусія називається. Хоча, напевно, десь була "історія успішних впроваджень". Значить, успішним його назвати поки що не можна через те, що впровадження не закінчилося як таке. Ви розумієте? Тобто ми зараз знаходимося в активній фазі виконання проекту як такого. Тож я можу сказати напевно про якісь уроки, які є на поточний момент, і не більше.
Про структуру: перше, просто щоб ви розуміли: структура нашої проектної команди на глобальному рівні - це 2 паралельні команди розробки. У нас є внутрішній центр компетенцій, який займається впровадженням, в тому числі і продуктів 1С:Підприємство. У нас є аналітики, і проектні менеджери, і люди, до них прирівняні. Принаймні, так вважається. У нас є розробники, у нас є партнер, з яким ми активно співпрацюємо. Так, це компанія «TQM systems». І ми в такому тандемі працюємо над впровадженням цієї системи.
На даний момент у нас є існуюча ERP-система, і це не є впровадженням нової. З самого початку це позиціонувалося як апгрейд існуючої. І ми самі трохи потрапили в капкан, який ми самі побудували, бо кілька разів повторили слово «апгрейд», - і це здавалося апгрейдом. Але, не дивлячись на те, що існуюча ERP-система є... і, здавалося б, якісь побудовані бізнес-процеси, автоматизації, вони є... З'ясувалося, що підхід до впровадження вимагає... воно ближче до впровадження з нуля, ніж апгрейду як такого.
Поточна система, вона запустилася в січні 11 року, абсолютно безшовно в порівнянні з попередньою системою, дуже гладко. І ось вона вже 8 років відпрацювала, власне, і вважаємо це одним з найбільш успішних кейсів ERP в нашому колі, тобто, вона працює на високому рівні. Чому ми взагалі вирішили міняти? З якого переляку, хотілося б дізнатися? Єдиним драйвером була ініціатива ІТ, ми зрозуміли, що накопиченим... Розумієте, є таке поняття, що метафори протікають. Чули про таке? Це з області системного аналізу, коли ми щось поділили, у нас є певна метафора. Згодом модельований об'єкт і модель починають віддалятися, і все це покривається певними милицями. Тобто, тимчасовими рішеннями, тому що метафора вже не може наздогнати. І коли їх стає занадто багато, ми просто відчули, що, по-перше, метафора себе вичерпала - компанія дуже сильно змінилася за ці 8 років. І вже зовсім нові вимоги, і ті архітектурні рішення, які 8 років тому були дуже вдалими, вони просто стали обмежуючим фактором для подальшого розвитку компанії.
І це бізнесу все було дуже зрозуміло, вони знали всі ці штуки. Ми з ними дуже тісно працюємо, і це рішення було прийнято дуже просто, еволюційно, без будь-якого опору, продавлювання, тиску з нашого боку, чи будь-яких негативних...
Тут я б додав, просто дійсно, напевно, в якій точці перебували, коли бізнес сам відчув, що це потрібно, і він зрозумів це на реальному прикладі. Як мінімум, в BAS ERP заявлені деякі функції і технології, які доступні, заявлені, підкреслюю, в коробці - в коробковому рішенні, - які впроваджуй - і користуйся вигодами. Те, що потрібно було нашій компанії як такій. Не потрібно було «вигадувати велосипед» як такий. Разом з тим, у нас в момент старту і коли ми почали активно про це говорити, у нас вийшов один з проектів. Це було впровадження мобільного клієнта для частини функціональностей, і воно дозволило колосально оптимізувати один з бізнес-процесів. І вони просто відчули це на реальному досвіді, яким чином ця технологія або зміна в якійсь точці які вигоди може принести. І вони просто підхопили це «на ура». Як сказав Євген, це була ІТ-ініціатива, але зараз всі вважають, що це не так.
Те, що стосується партнера, нехай партнер відповість.
Тим більше, що прийшов час дати йому слово. Так.
Максим Зосим, директор «TQM systems»:
Відразу відповім на питання: з нашого боку працює 14 осіб. Це те, що стосується інженерів безпосередньо: аналітики, розробники. І другий пункт, який необхідно аналізувати. Те, що важливо. Якщо подивитися на зал, тобто половина - це люди, які впроваджують цей продукт, а половина - ті, хто застосовує і буде застосовувати - розглядають використання цього продукту. І якщо ви порівнюєте, якщо у вас є якийсь попередній досвід, правильно говорить Роман: сприймати це як апгрейд або ще один проект на платформі 1С:Підприємство геть зараз неправильно.
Починав я свою діяльність як бізнес-аналітик, і сертифікований з УВП. Це був найважчий і складний продукт і, тим не менше, ці продукти, вони вміщалися в голові. Таким ось простим визначенням - вміщалися в архітектурі в голову однієї людини. Тобто одна людина, якщо мені зараз відкрити УВП, я вам розповім архітектуру: ось це для цього, для цього, тут якісь об'єкти, документи і так далі.
BAS ERP в голову однієї людини не вміщається. Мало того, воно не вміщається в голову і 5-6 чоловік. На кожен модуль: він настільки ускладнився з точки зору взаємодії з іншими модулями, з точки зору того, як він працює, і від яких параметрів залежить... Ми для того, щоб ось з колегами синхронізувати його з тестовою базою... У BAS ERP 219 функціональних галочок, які вмикають або вимикають цілі області функціоналу. Тобто для того, щоб по-іншому поводилася система.
Якщо раніше ви бачили все візуально, то зараз є цілий ряд опцій, які цей функціонал не показують або показують.
Тому команди, які є зараз, дуже сильно збільшилися: сумарна кількість інженерів у проекті з 2-х сторін - близько 30. Кількість людей, що беруть участь в проекті разом з експертами, - близько 50. І це дуже сильно змінює структуру проекту: якщо раніше ви могли покласти впровадження там УТП або УВП на 10 фахівців, і дуже часто стояло питання: «Ми самі впроваджуємо або передаємо весь процес на аутсорсинг?», то зараз постало питання з "і": «Ми і самі впроваджуємо, і передаємо частину процесу на аутсорсинг?». Тому що, якщо відповідати на питання Сергія з приводу методології, насправді ми користуємося не одною методологією в проекті, у нас різні вимоги до документів. Дуже добре на одній із зустрічей озвучував Роман, задавали питання: "Чому ваші внутрішні документи 20 сторінок, а наші зовнішні документи за схожим функціоналом - 90 сторінок?" І відповідь була гарна, тому що "нам треба зрозуміти, що ви нас зрозуміли, а те, що ми самі це розуміємо, ми і так знаємо". І в цьому є різниця.
Тому, якщо дивитися на план-графік проекту, то це начебто класичний Waterfall - моделювання, розробки і т.д. Якщо копнути всередину кожного з цих пунктів, то там в масі речей - класичний Agile: ітерації, планування аж до тижневого заряду модулів, які нам передавалися в розробку. Ось це мікс такий великий і є.
Євген Осьмак, Head of corporate IT, “Zeppelin”:
Я б так і сказав: на верхньому рівні - Waterfall, на рівні великих функціональних одиниць, а кожна функціональна одиниця залежно від Канбану або ближче до Канбану, якщо це внутрішні, або якщо зовнішні там ітерації, і я не виділив би якусь чисту методологію. Але в Agile головне - щоб не настав Agile головного мозку.
Давайте я ще додам один фактор, який всі завжди забувають. Ми однаковими термінами називаємо для різного розміру компаній абсолютно різні речі. Тому що для однієї компанії... ось є 2 вхідних замовника і один називає: нам потрібне бюджетування або казначейство для одної компанії. Торговельна, 20 осіб, і для них казначейство означає, що є заявка на витрачання грошових коштів, в якій директор ставить галочку, що це платимо, а це не платимо. І називається це казначейство. І є казначейство з розряду ось Zeppelin, коли є ліміти, бюджети, інвестиції, все це один одному підпорядковане, входить... Ось потрібно мати різницю в цій термінології. Те, що ви називаєте максимум, - це зовсім не те саме, що у людей, які стільчики виробляють поштучно або на замовлення, а називають вони насправді теж там планування в такій же методології. Це дуже важливий фактор насправді - це перше.
Друге, коли ми говоримо про моделювання процесів з приводу as is, to be та іншого, треба розуміти зрілість компанії. Якась компанія готова моделювати as is, to be і матрицю переходу з as is в to be. Таким чином, ми цей крок, власне кажучи, зробимо, від цих процесів перейдемо сюди, тому що вони пов'язані не тільки з автоматизацією. Вони пов'язані з організаційними змінами, з процесними змінами, з реінжинірингом оргструктури в деяких випадках, які залежать від цих систем. А є компанії, у яких до цього не було цих термінів, вони не розуміють, навіщо взагалі 3 ось ці формати. І ми можемо говорити, що робіть ось так, як в типовому функціоналі. І вони готові змінювати свої бізнес-процеси, тому що вони не розуміють їх зараз, ніколи їх не моделювали. І такий номінальний факт, що в системі є ось так, це і буде вашим to be, вони приймають. Ось 2 фактори, які не варто забувати.
Ось ви говорили: дуже гнучка система, 216 галочок, щось там налаштовується... І, тим не менш, у вашому випадку в Zeppelin, це там 10 тисяч годин програмування, десь ще величезна кількість годин програмування. Чи був у вашому випадку у TQM-а варіант впровадження з коробки, тобто без програмування? Тобто як би ідеальна ситуація, купив - поставив - всі щасливі.
Так, насправді, це 2 підходи абсолютно різні. Зараз вже немає такого поняття, «поставив і всі щасливі». Просто навіть щоб визначити, які з цих галочок повинні бути включені для вашого підприємства, а які - не включені, тільки ось цей етап вимагає досить великого часу, це перше.
Друге - з приводу трудовитрат в проекті. Раніше трудовитрати з проекту на базі 1С:Підприємство розподілялися приблизно 25 на 75%, тобто 25% - це аналіз, моделювання, взаємодія аналітика з користувачем, і 75 - це програмування, все, що з цим пов'язане, там тестування, адаптація перекидання та інше. Зараз кардинально різні цифри: зараз етап моделювання займає 60% на 40% програмування. Це не "допрограмування" в такому обсязі, це процес моделювання і прийняття того, як ми будемо працювати в системі, розумієте?
Тобто це розуміння, як ті галочки налаштувати, тобто це більше налаштування, ніж програмування?
Не тільки в цьому питанні. У деяких моментах, що і де потрібно допрограмувати, щоб процес запрацював. Іноді потрібно витратити 100 годин, щоб описати, що допрограмувати і потім за 20 допрограмувати.
Ну або міняти to be і процес.
Так.
Знову ж таки, для того, щоб краще зрозуміли диспозицію, тому що правильно Максим абсолютно каже, слова однакові, а зміст різний. Компанія Zeppelin має надзвичайно тісну процесну інтеграцію з основним вендором компанії. Процесну, не на рівні даних, не на рівні, знаєте, такої взаємодії. Це процесна інтеграція, ми практично двома ділянками одного і того самого потоку створення цінності, і це призводить до значної кількості абсолютно унікальних функціональностей, яких не можна очікувати від будь-якої системи. Це зрозуміло - специфіка. І така сама специфіка є в іншу сторону. Буквально, компанія Zeppelin процесно інтегрована з найбільшими замовниками. Це великі українські гірничозбагачувальні комбінати, і там теж процесна інтеграція з їх ЕРП-частиною. Ці дві штуки, вони вносять такий елемент, якого не можна очікувати з будь-якої коробки.
Велике число доопрацювань.
Або, проте, кількість кастомізацій або адаптацій значна. І я б був готовий на окрему полеміку в режимі афтер-паті. Наскільки взагалі мрія про систему, яка буде підходити більше, ніж одній компанії, випущена вендором, буде підходити більше, ніж одній вузькій ніші, яка буде з коробки щось там покривати? Наскільки взагалі цю ідею можна в маси запускати, в свою голову, для того щоб не відриватися від дійсності?
Теорема Геделя про неповноту, наприклад, - zum beispiel, говорить про наступне: що у нетривіальної системи може бути 3 характеристики: універсальність - покриває всі галузі, повнота - покриває всі бізнес-процеси, і внутрішня логічна несуперечливість - тобто "не глючить", по-нашому. Ну, ви ж розумієте, до чого я хилю: оберіть будь-які 2. Якщо я роблю рішення як вендор, ну ніхто не хоче рішення це з глюками. Значить, ми ставимо 2 альтернативи: або я пишу рішення, яке жорстко заточене під певну галузь і не виходить за її рамки - і я працюю тільки з цією окремою вузькою галуззю. Чим вужче - тим краще.
Або я роблю систему, яка буде універсальною, але вона при цьому буде неповною, тобто кожному доведеться... вона підходить кожному, але кожен повинен далі привносити 40% свого сенсу, або 30 або 70, або, може, як піде. І тут всі 3 компоненти одночасно - ну, для мене це сама постановка питання така, яка викликає бажання її обговорити.
З іншого боку, ці 216 галочок, які присутні в BAS ERP, говорять про те, що вони хотіли цими налаштуваннями і покрити максимально функціонал і ...
Система BAS ERP говорить про те, що горизонтально ця система намагається покрити всі галузі і бути системою, яка претендує на універсальність, так, на догоду повноті. Вона автоматично буде неповною. Це або 5 міліметрів вглиб, в кожному процесі, або ви їх всі бачите, але якщо вам треба 7, беремо лопатку, зубочистку, екскаватор, - у кого вже що є, - і копати, ось. Або ця глибина, в залежності від світосприйняття вендора і тієї методологічної команди... Ви ж розумієте, там теж люди сидять, і, може, там вони взяли тих, хто раніше працював з виробництвом, з цим, з тим, але вони як я в апельсинах проти продажу або маркетингу, або дистрибуції там, HR того ж, або ще чогось. В результаті кожна система має унікальну комбінацію цих заглиблень. Але з точки зору вендора, поставте там на місце SAP, 1C або, я не знаю, Microsoft, - вони хочуть універсальність, тому що кому вони будуть продавати? Трьом клієнтам в одній галузі?
Ну, не покриють вони точками площину, це ж математика. Хоча хочеться.
А так іноді простого хочеться рішення!
Пардон, це була політична реклама .
Андрій Янбухтін. Архітектор діджитал-екосистем:
З точки зору цифрової трансформації - це новий модний термін, цифрова трансформація. Чому так називають? Тому що всі компанії вважають, що вони Діджитал. Точно, ви не знайдете компанію, яка скаже: "Ну що ви, ми аналогова компанія". Всі діджитал. І ми діджитал злегка трансформуємо, ми стаємо кращими.
Григорій Лісничний, CIO "Moneyveo":
Можна навіть так сказати: діджиталізація і цифровізація бізнесу - вона вже в нас.
Олексій Мовчан, керівник напрямку розвитку КІС "Міжнародний аеропорт Бориспіль":
Для початку скажу, що дійсно на сьогоднішній день сприймаю це модне слово як ще один синонім і спробу обізвати те, що ми вже багато років маємо насправді.
Володимир Бузмаков, голова спільноти ІТ-директорів України:
Тут картинка така. Ми там говорили про автоматизацію: ось автоматизація, так. Далі говоримо інформатизація. Потім починаємо різні трилітерні абревіатури: там ERP, CRM, B2B, B2C, ще що-небудь. Хоча брешу: B2B - воно ось так пішло, B2C так пішло, ще щось, ще... Тут вже є і такий шар, і такі. А діджиталізація виглядає якось ось так, іноді ось так, іноді ще якось, от...
Моє глибоке переконання, коли ось говорили... Воно було ще не дуже глибоким, але тут вже так поглибилося: спроба зробити діджиталізацію ось такою просто приречена на крах. Може, хтось іншої думки - переконайте.
Максим Зосим, директор «TQM systems»:
Ось те, що ви намалювали зараз, взагалі в термінології світових корпорацій називається "дизраптинг" - коли всередині корпорації виділяють незалежних людей, які ні від кого не залежать, і намагаються зробити бізнес-модель, яка вб'є їх же бізнес. Тому що, якщо вони цього не зроблять, за них це зробить хтось інший. Це вся методологія стартапів, яка навколо цього утворювалася. Найчастіше чому не виходить зробити всередині корпорації? Тому що у людини багато лінійних горизонтальних і вертикальних зв'язків, вони не можуть це зробити, і виділяються люди, які намагаються змінити, як ми можемо себе ж вбити, і це завдання має схожу дуже картинку.
Володимир Бузмаков, голова співтоваритства ІТ-директорів України:
Я навіть здогадуюся, чому. Тому що у нас все йде до філософії насправді і до накопиченої людством кількості знань.
Наскільки я пам'ятаю, останній раз дерево знань малювали приблизно в 16-17 столітті. Яке вміщувалося в головах людей. Тепер такого вже не малюють, тому що не виходить, - занадто багато згенеровано.
Євген Осьмак, Head of corporate IT, “Zeppelin”:
Я хочу підтвердити тезу 2-х попередніх ораторів ілюстрацією. Компанія Zeppelin конкретно займається тим, про що говорив Максим. Ми провели ряд воркшопів і зараз згенерували 2 стартапи з підриву нашої власної бізнес-моделі. Робиться прям ось конкретно. І зараз в Німеччині, в Баварії проходить одна з найбільших в світі виставок будівельної техніки, яка називається Баума. І цей стартап, який повинен підірвати нашу ж індустрію, виведений на ринок під альтернативним брендом. Це просто ілюстрація: те, про що говорив Максим в теоретичному сенсі, Zeppelin робить в практичному.
Що? На цьому закінчимо, так?
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