Почему понадобилось внедрение нового продукта. Как подошли к выбору, чем был обусловлен. С чем столкнулись на первом этапе внедрения, какие извлекли уроки. В чем разница между новым продуктом 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-2025 TQMsystems. Все права защищены. Privacy Policy | Terms of Service