Наша ERP-платформа разработана для ИТ, но все бизнес-подразделения могут ее использовать.
Источник:
it-world
Мы интегрируемся с классом решений «1С». Это «1С:Бухгалтерия», «1С:ЗУП». Мы на данный момент не храним финансово чувствительные данные в учетной системе.
В чем недостатки единой модели данных по всем бизнес-процессам?
К недостаткам единой модели данных можно отнести примерно те же недостатки, что и в обычных монолитных архитектурах любых ИТ-сервисов. Со временем появляется избыточная сложность использования такой модели данных. Она растет, усиливается какими-то механизмами, дополнительными расчетами. В таких случаях выявляется явная дороговизна в развитии и поддержке единой модели данных. К тому же не совсем верно считать, что у единой модели данных одна ответственная служба, которая владеет этими данными. Единая модель данных в любом случае логически разделяется по зонам контекста или по бизнес-ценности, у которой будут свои владельцы и потребители этих данных. Еще есть важный недостаток – это техническая ограниченность развития. Если бизнес осознает, что пора переводить работу с данными на более современный технологический стек или повышаются требования к ИБ, техническому окружению этих данных, то переносить на новый стек по частям невозможно. Вся модель будет с нуля подвержена изменениям. Понадобится серьезная подготовка, которую будет осуществлять большая команда, опять же стоимость всего этого дела возрастет.
В каком году вы начали работать над своей ERP-системой?
Наиболее активная разработка нашей ERP-системы началась в начале 2021 года, когда мы получили последствия кратного роста компании и изменения принципов управления компанией в ковидный период. Штат у нас пополнялся очень активно – каждую неделю десятками специалистов. Портфель проектов и вся управляемость проектов перестали помещаться на страничке Excel. Прозрачности потребовалось больше. Самое главное, что потребовался чуть ли не онлайн-режим принятия решений. То есть нужны были механизмы, которые автоматически, по сути, позволяли бы нам принимать решение о бизнесе, о проектах, о метриках компании. Тогда активная разработка стартовала.
Интеграцию модулей с какими системами вы осуществляли?
Их немного. У нас достаточно базовая интеграция. Мы интегрируемся с классом решений «1С». Это «1С:Бухгалтерия», «1С:ЗУП». Мы не храним финансово чувствительные данные в учетной системе на данный момент. Также мы интегрируемся с корпоративной службой каталогов, знакомой всем Active Directory. Поэтому мы должны с такими службами уметь интегрироваться. И наш продукт интегрируется с ними из коробки. Подключение к AD обязательно.
Что нового появилось в вашей ERP-системе, чего не было в продуктах Oracle и SAP?
Не скажу, что мы разительно отличаемся. Все же исторически продукты этих компаний заложили принципы достойных ERP-систем. Наш продукт обладает чуть большей технологической гибкостью за счет разделения учетной и аналитической системы и выделения модели данных в единую для всей компании. Поскольку пользователи продукта – это множество бизнес-подразделений, часть которых больше времени проводит в учетной системе, часть – в аналитической, либо смешанно. В продуктах Oracle и SAP была значительная отраслевая бизнес-специфика. Например, какое-то бизнес-подразделение пользовалось продуктом класса решений SAP, например SAP HR. Для других бизнес-подразделений, во-первых, это не очень прозрачно. Если используются другие продукты без интеграции с SAP HR или другие базы данных, то происходит разрыв между бизнес-доменами на уровне данных. Хотя этого можно не допустить, но только всю компанию или все системы компаний переводя на единый класс, тот же SAP или Oracle целиком. У нас реализована модульность бизнес-решений, как и в Oracle или SAP, но улучшена технологическая гибкость за счет раздельных модели данных, учетной и аналитической систем. Можно сказать, мы отличаемся этим, хотя и тоже имеем некую отраслевую специфику. У нас ERP-платформа для ИТ, но вся компания, все бизнес-подразделения могут ее использовать. Я отмечу здесь ее гибкость.
В чем достоинства долгосрочного data-driven-подхода к управлению всеми внутренними процессами?
Подход на основе данных. Что здесь можно отметить? Вообще подход на основе данных позволяет оптимизировать использование ресурсов, очень важных для ИТ-компаний. Это время, деньги, человеческий капитал. Вот мы – ИТ-компания, и нам как раз эти три составляющие дороже всего. И все решения, принятые на основе данных, можно считать обоснованными. На уровне компаний сформирована позиция, что мы полагаемся на данные, не на субъективные мнения, даже если они экспертные. Делаем это осознанно, не для чьей-либо выгоды. Чтобы у нас не было недосказанности в каких-либо вопросах на всех уровнях управления компанией. И я думаю, что компании, которые используют data-driven-подход, обычно быстрее адаптируются к изменениям, становятся лидерами в своих рыночных нишах. Мне кажется, так и случилось в 2022 году, когда мы очень быстро среагировали на все изменения, сохранили темпы роста бизнеса. Очень быстро определили, на каких проектах и метриках стóит особенно сосредоточиться. Мы практически не потеряли специалистов, а это главная ценность ИТ-компаний. И этому очень способствует подход принятия решения на основе данных.
Что у вас появилось нового по отношению к российским ERP-системам?
Мы особенно сосредоточены на ресурсном планировании не в типовых условиях, на управлении ИТ-командами. Нельзя сказать, что сейчас российские ERP-системы обращают внимание на тонкости управления нетиповой проектной загрузкой команд. В ИТ-бизнесе непросто что-либо типизировать. Приведу пример. Многие российские ERP-системы, зарекомендовавшие себя, умеют нормировать время, трудозатраты практически всех специалистов по ролям, компетенциям и тому подобное. Но в ИТ практически ничего не типизируется в проектах. Даже если задача звучит примерно одинаково, как и в прошлом проекте у другого заказчика, мы не можем однозначно полагаться на прошлую оценку сложности реализации или длительности этой задачи. К тому же многие ERP-системы недооценивают повышенную кросс-функциональность и зависимость одних специалистов от других, что характерно для ИТ, и это очень влияет на простои или риски переработок. Все эти тонкости мы пытаемся учитывать как раз в нашем подходе к ресурсному планированию, которое мы автоматизировали у себя в продукте. Это отличает нас от привычных ERP-платформ в России.
Что даст разработчикам анализ рисков на ранних этапах проектирования?
Анализ рисков – это традиционный шаг в управлении проектами. Мы его не можем игнорировать, особенно сегодня. Даже если на ранних этапах проектирования риски кажутся маловероятными. Но вообще анализ рисков для исполнителей или для заказчиков – это инструмент для конкретных акцентов, чтобы сосредоточить внимание всех лиц, принимающих решение, на конкретном проекте, на принятом или как раз наоборот, непринятом решении. Все-таки однозначно определиться и всем согласованно отметить, что мы либо хотим управлять риском, либо не хотим, мы его осознанно избегаем или принимаем. Реестр рисков очень быстро позволяет актуализировать то, что мы наметили даже на ранних этапах проектирования, или подсветить новые проблемы. Не избегать их осознанно, а как раз-таки принять единое решение для всех, что мы либо принимаем, либо избегаем, либо решаем, либо даже не можем повлиять.
Что даст заказчикам использование ИИ в вашей экосистеме?
Я уже упоминала про главную особенность продукта – это ресурсное планирование именно для ИТ-бизнеса, для ИТ-команд. Мы хотим с помощью ИИ, по сути, нарабатывать данные и формировать обучаемую модель, которая впоследствии свяжет производственный план, или так называемый портфель проектов, или портфель сделок, если это чисто коммерческий ИТ-бизнес, с вероятностями наступления тех или иных сделок. И отсюда подстраивать ресурсные планы автоматически, исходя из оперативного анализа, то есть доступности всех специалистов, мощности ИТ-команд, конкретных специалистов с набором нужных скилов или грейдов для решения проекта, который находится внутри производственного плана со своей вероятностью наступления. ИИ был бы достаточно неплохим помощником для этого решения. Он хотя бы сократит время. Я почти уверена, что ИИ на текущем этапе не способен совсем заменить человеческое принятие решения вокруг формирования ИТ-команд, но сократить время на это точно можно.
Что дала интеграция вашей ERP-системы и системы «1С»?
«1С» для нас – мастер-система финансово чувствительных данных. И мы не откажемся, я думаю, от такого подхода, по крайней мере на российском рынке. То есть мы его сохраняем и развиваем, чтобы уметь интегрироваться с «1С» с бóльшими версиями и так далее. Потому что, во-первых, «1С» – довольно популярное решение для любого бизнеса, особенно в области источника данных на тему финансов, зарплат, реального штатного расписания и подобных вещей, которые не хранятся специально в других ИТ-продуктах. Во-вторых, повышенная точность и прозрачность. То, о чем мы говорили касательно нашей ERP-системы, помимо того что мы все плановые значения забираем из учетной системы, мы подтягиваем к ним фактические значения из «1С», особенно по таким понятным финансовым категориям, как выручка, маржинальность проектов, себестоимость затрат на ИТ-команды или конкретные договоры подрядчиков, и такие вещи, которые незаметно, но потом в совокупности влияют на все финансовые метрики эффективности проектов. И мы можем очень быстро провести план-факт-анализ, насколько качественно мы запланировали у себя в учетной системе все затраты или метрики проекта и как мы их выполнили по факту с учетом данных из «1С».
Что вы планируете добавить в ваш CRM-модуль в его второй версии?
Наш CRM-модуль сейчас предназначен для оперативной работы отдела продаж. Мы хотим улучшить связь между всеми сделками, вероятностями их наступления, с метриками проектов, которые реализуются, по сути, после совершения этих сделок. Это будет более качественный и глубокий план-факт-анализ, сколько длилась сделка, какую экспертизу мы привлекали для свершения этой сделки, какие метрики эффективности бизнеса мы запланировали на старте этой сделки, а с другой стороны, что мы получили на выходе с точки зрения проекта по его качеству, финансовым метрикам и совпали ли результаты эффективности этого проекта с ожиданиями бизнеса от этой сделки. Это будет более полный аналитический срез, связь нашего CRM-модуля во второй версии с проектной деятельностью.
Сколько всего у вас было product owner и все ли они одинаково вели свою часть проекта?
У нас порядка восьми владельцев продукта, потому что у нас модульный продукт. Например, модуль управления проектами и ресурсами курируют в разных элементах три владельца продукта. Это операционный директор, руководитель проектного офиса и руководитель направления. За аналитическую составляющую, связанную с эффективностью финансов, отвечает другой владелец продукта – финансовый директор. Коммерческий директор является владельцем логики модуля CRM, HR-директор и руководитель направления развития и обучения курируют HR-модуль. Генеральный директор компании проверяет на прочность логику модуля стратегического управления Орион GOAL. Все восемь владельцев продукта одинаково погружены в свою часть проекта. Они формируют концептуальные требования. Они могут приоритизировать все фичи, которые предлагаются в рамках этих функциональных требований. Они выставляют в том числе метрики качества к тому, как эти фичи должны быть в целевом состоянии реализованы.
Сколько клиентов сейчас эксплуатируют вашу ERP-систему?
Коммерческое внедрение нашего продукта началось с конца 2022 года. У нас два клиента эксплуатируют систему. Помимо этого, два проекта в пилотной стадии. Наш продукт можно пилотировать с понятными критериями приемки, в том числе на нашей инфраструктуре, заранее определенное количество времени, с принятием решений о дальнейшем внедрении. Продукт можно пилотировать в том числе на особенностях бизнес-процессов или данных потенциального заказчика. Соответственно, у нас два клиента на эксплуатации и два пилота.
С какими системами вы планируете интегрировать вашу ERP-систему?
Что я здесь могу подсветить? Мы точно сохраним практику интеграции нашей системы с классом решений «1С». Также мы сейчас находимся в процессе импортозамещения нашего продукта и понимаем, что на некоторые модули, самые популярные – это ресурсное планирование или проектное управление, – я думаю, имеет смысл написать собственное API, что для дальнейшей интеграции с другими российскими платформами будет максимально эффективно. Например, мы сможем интегрировать с помощью API модуль ресурсного планирования с другой российской системой по управлению проектами, забирая данные о плановых или фактических метриках и отдавая сценарии распределения ИТ-команд. Или мы можем интегрировать наш модуль проектного управления через API – то, как мы ведем метрики, планируем и контролируем проект, – с инструментами task tracking, из которых мы бы забрали фактическую эффективность команд на ИТ-проектах и представили через аналитическую систему план-фактный анализ. Я думаю, мы будем развивать подобного рода интеграции.
Что вам дали конкуренты в плане совершенствования ERP-систем? Что они подсказали?
Сложный вопрос. Точно есть вещи у конкурентов, которые мы перенимаем с точки зрения традиционного проектного управления не по гибким методологиям, потому что ИТ-бизнес чаще работает с проектами в формате гибких методологий. Мы смотрим на современную реализацию самых критичных интересных фичей, связанных с традиционным проектным управлением даже в ИТ. Также обращаем внимание на современные платформы по управлению бизнес-процессами (BPM-платформы), чтобы дать больше удобства бизнес-пользователям, которые не привыкли к интерфейсам айтишников, чтобы улучшить их user experience. Вот что чаще всего мы подсматриваем у конкурентных решений.
Сколько кросс-функциональных команд вы создали и как они взаимодействовали в процессе создания вашей ERP-системы?
У нас две постоянные кросс-функциональные команды, которые взаимодействуют друг с другом. Самое основное, что у нас есть команда, которая работает над текущей эксплуатацией продукта. Потому что, опять же, мы сами являемся клиентами своего продукта и пользователями его. Одна команда сформирована для эксплуатации и поддержки технического качества продукта. Вторая команда – продуктового типа, более ориентированная на сопровождение и адаптацию клиентов, развитие функциональности продукта. Особенно если мы говорим про «пилоты» с потенциальными заказчиками. Отдельно мы можем создавать команду, тоже кросс-функциональную, которая будет внедрять продукт уже у заказчика, на его данных и бизнес-процессах. Наша система очень гибкая. Часто приходят запросы на кастомизацию под некоторые особенности бизнеса наших заказчиков. Соответственно, лучше выделять отдельную команду. Она может быть кросс-функциональной с использованием специалистов из текущих команд, которые уходят на внедрение и адаптацию продукта под клиента. У каждой команды есть руководитель проекта. В продуктовом офисе происходит связь между тем, как работают команды непосредственно в своей зоне ответственности, и как это влияет на продукт. Сверяем часы по направлению движения продукта, по его развитию и дальнейшим задачам отдельно с владельцами продукта через инвестиционный комитет. С горизонтальными и вертикальными коммуникациями у нас не возникает проблем.
В чем недостатки единой модели данных по всем бизнес-процессам?
К недостаткам единой модели данных можно отнести примерно те же недостатки, что и в обычных монолитных архитектурах любых ИТ-сервисов. Со временем появляется избыточная сложность использования такой модели данных. Она растет, усиливается какими-то механизмами, дополнительными расчетами. В таких случаях выявляется явная дороговизна в развитии и поддержке единой модели данных. К тому же не совсем верно считать, что у единой модели данных одна ответственная служба, которая владеет этими данными. Единая модель данных в любом случае логически разделяется по зонам контекста или по бизнес-ценности, у которой будут свои владельцы и потребители этих данных. Еще есть важный недостаток – это техническая ограниченность развития. Если бизнес осознает, что пора переводить работу с данными на более современный технологический стек или повышаются требования к ИБ, техническому окружению этих данных, то переносить на новый стек по частям невозможно. Вся модель будет с нуля подвержена изменениям. Понадобится серьезная подготовка, которую будет осуществлять большая команда, опять же стоимость всего этого дела возрастет.
В каком году вы начали работать над своей ERP-системой?
Наиболее активная разработка нашей ERP-системы началась в начале 2021 года, когда мы получили последствия кратного роста компании и изменения принципов управления компанией в ковидный период. Штат у нас пополнялся очень активно – каждую неделю десятками специалистов. Портфель проектов и вся управляемость проектов перестали помещаться на страничке Excel. Прозрачности потребовалось больше. Самое главное, что потребовался чуть ли не онлайн-режим принятия решений. То есть нужны были механизмы, которые автоматически, по сути, позволяли бы нам принимать решение о бизнесе, о проектах, о метриках компании. Тогда активная разработка стартовала.
Интеграцию модулей с какими системами вы осуществляли?
Их немного. У нас достаточно базовая интеграция. Мы интегрируемся с классом решений «1С». Это «1С:Бухгалтерия», «1С:ЗУП». Мы не храним финансово чувствительные данные в учетной системе на данный момент. Также мы интегрируемся с корпоративной службой каталогов, знакомой всем Active Directory. Поэтому мы должны с такими службами уметь интегрироваться. И наш продукт интегрируется с ними из коробки. Подключение к AD обязательно.
Что нового появилось в вашей ERP-системе, чего не было в продуктах Oracle и SAP?
Не скажу, что мы разительно отличаемся. Все же исторически продукты этих компаний заложили принципы достойных ERP-систем. Наш продукт обладает чуть большей технологической гибкостью за счет разделения учетной и аналитической системы и выделения модели данных в единую для всей компании. Поскольку пользователи продукта – это множество бизнес-подразделений, часть которых больше времени проводит в учетной системе, часть – в аналитической, либо смешанно. В продуктах Oracle и SAP была значительная отраслевая бизнес-специфика. Например, какое-то бизнес-подразделение пользовалось продуктом класса решений SAP, например SAP HR. Для других бизнес-подразделений, во-первых, это не очень прозрачно. Если используются другие продукты без интеграции с SAP HR или другие базы данных, то происходит разрыв между бизнес-доменами на уровне данных. Хотя этого можно не допустить, но только всю компанию или все системы компаний переводя на единый класс, тот же SAP или Oracle целиком. У нас реализована модульность бизнес-решений, как и в Oracle или SAP, но улучшена технологическая гибкость за счет раздельных модели данных, учетной и аналитической систем. Можно сказать, мы отличаемся этим, хотя и тоже имеем некую отраслевую специфику. У нас ERP-платформа для ИТ, но вся компания, все бизнес-подразделения могут ее использовать. Я отмечу здесь ее гибкость.
В чем достоинства долгосрочного data-driven-подхода к управлению всеми внутренними процессами?
Подход на основе данных. Что здесь можно отметить? Вообще подход на основе данных позволяет оптимизировать использование ресурсов, очень важных для ИТ-компаний. Это время, деньги, человеческий капитал. Вот мы – ИТ-компания, и нам как раз эти три составляющие дороже всего. И все решения, принятые на основе данных, можно считать обоснованными. На уровне компаний сформирована позиция, что мы полагаемся на данные, не на субъективные мнения, даже если они экспертные. Делаем это осознанно, не для чьей-либо выгоды. Чтобы у нас не было недосказанности в каких-либо вопросах на всех уровнях управления компанией. И я думаю, что компании, которые используют data-driven-подход, обычно быстрее адаптируются к изменениям, становятся лидерами в своих рыночных нишах. Мне кажется, так и случилось в 2022 году, когда мы очень быстро среагировали на все изменения, сохранили темпы роста бизнеса. Очень быстро определили, на каких проектах и метриках стóит особенно сосредоточиться. Мы практически не потеряли специалистов, а это главная ценность ИТ-компаний. И этому очень способствует подход принятия решения на основе данных.
Что у вас появилось нового по отношению к российским ERP-системам?
Мы особенно сосредоточены на ресурсном планировании не в типовых условиях, на управлении ИТ-командами. Нельзя сказать, что сейчас российские ERP-системы обращают внимание на тонкости управления нетиповой проектной загрузкой команд. В ИТ-бизнесе непросто что-либо типизировать. Приведу пример. Многие российские ERP-системы, зарекомендовавшие себя, умеют нормировать время, трудозатраты практически всех специалистов по ролям, компетенциям и тому подобное. Но в ИТ практически ничего не типизируется в проектах. Даже если задача звучит примерно одинаково, как и в прошлом проекте у другого заказчика, мы не можем однозначно полагаться на прошлую оценку сложности реализации или длительности этой задачи. К тому же многие ERP-системы недооценивают повышенную кросс-функциональность и зависимость одних специалистов от других, что характерно для ИТ, и это очень влияет на простои или риски переработок. Все эти тонкости мы пытаемся учитывать как раз в нашем подходе к ресурсному планированию, которое мы автоматизировали у себя в продукте. Это отличает нас от привычных ERP-платформ в России.
Что даст разработчикам анализ рисков на ранних этапах проектирования?
Анализ рисков – это традиционный шаг в управлении проектами. Мы его не можем игнорировать, особенно сегодня. Даже если на ранних этапах проектирования риски кажутся маловероятными. Но вообще анализ рисков для исполнителей или для заказчиков – это инструмент для конкретных акцентов, чтобы сосредоточить внимание всех лиц, принимающих решение, на конкретном проекте, на принятом или как раз наоборот, непринятом решении. Все-таки однозначно определиться и всем согласованно отметить, что мы либо хотим управлять риском, либо не хотим, мы его осознанно избегаем или принимаем. Реестр рисков очень быстро позволяет актуализировать то, что мы наметили даже на ранних этапах проектирования, или подсветить новые проблемы. Не избегать их осознанно, а как раз-таки принять единое решение для всех, что мы либо принимаем, либо избегаем, либо решаем, либо даже не можем повлиять.
Что даст заказчикам использование ИИ в вашей экосистеме?
Я уже упоминала про главную особенность продукта – это ресурсное планирование именно для ИТ-бизнеса, для ИТ-команд. Мы хотим с помощью ИИ, по сути, нарабатывать данные и формировать обучаемую модель, которая впоследствии свяжет производственный план, или так называемый портфель проектов, или портфель сделок, если это чисто коммерческий ИТ-бизнес, с вероятностями наступления тех или иных сделок. И отсюда подстраивать ресурсные планы автоматически, исходя из оперативного анализа, то есть доступности всех специалистов, мощности ИТ-команд, конкретных специалистов с набором нужных скилов или грейдов для решения проекта, который находится внутри производственного плана со своей вероятностью наступления. ИИ был бы достаточно неплохим помощником для этого решения. Он хотя бы сократит время. Я почти уверена, что ИИ на текущем этапе не способен совсем заменить человеческое принятие решения вокруг формирования ИТ-команд, но сократить время на это точно можно.
Что дала интеграция вашей ERP-системы и системы «1С»?
«1С» для нас – мастер-система финансово чувствительных данных. И мы не откажемся, я думаю, от такого подхода, по крайней мере на российском рынке. То есть мы его сохраняем и развиваем, чтобы уметь интегрироваться с «1С» с бóльшими версиями и так далее. Потому что, во-первых, «1С» – довольно популярное решение для любого бизнеса, особенно в области источника данных на тему финансов, зарплат, реального штатного расписания и подобных вещей, которые не хранятся специально в других ИТ-продуктах. Во-вторых, повышенная точность и прозрачность. То, о чем мы говорили касательно нашей ERP-системы, помимо того что мы все плановые значения забираем из учетной системы, мы подтягиваем к ним фактические значения из «1С», особенно по таким понятным финансовым категориям, как выручка, маржинальность проектов, себестоимость затрат на ИТ-команды или конкретные договоры подрядчиков, и такие вещи, которые незаметно, но потом в совокупности влияют на все финансовые метрики эффективности проектов. И мы можем очень быстро провести план-факт-анализ, насколько качественно мы запланировали у себя в учетной системе все затраты или метрики проекта и как мы их выполнили по факту с учетом данных из «1С».
Что вы планируете добавить в ваш CRM-модуль в его второй версии?
Наш CRM-модуль сейчас предназначен для оперативной работы отдела продаж. Мы хотим улучшить связь между всеми сделками, вероятностями их наступления, с метриками проектов, которые реализуются, по сути, после совершения этих сделок. Это будет более качественный и глубокий план-факт-анализ, сколько длилась сделка, какую экспертизу мы привлекали для свершения этой сделки, какие метрики эффективности бизнеса мы запланировали на старте этой сделки, а с другой стороны, что мы получили на выходе с точки зрения проекта по его качеству, финансовым метрикам и совпали ли результаты эффективности этого проекта с ожиданиями бизнеса от этой сделки. Это будет более полный аналитический срез, связь нашего CRM-модуля во второй версии с проектной деятельностью.
Сколько всего у вас было product owner и все ли они одинаково вели свою часть проекта?
У нас порядка восьми владельцев продукта, потому что у нас модульный продукт. Например, модуль управления проектами и ресурсами курируют в разных элементах три владельца продукта. Это операционный директор, руководитель проектного офиса и руководитель направления. За аналитическую составляющую, связанную с эффективностью финансов, отвечает другой владелец продукта – финансовый директор. Коммерческий директор является владельцем логики модуля CRM, HR-директор и руководитель направления развития и обучения курируют HR-модуль. Генеральный директор компании проверяет на прочность логику модуля стратегического управления Орион GOAL. Все восемь владельцев продукта одинаково погружены в свою часть проекта. Они формируют концептуальные требования. Они могут приоритизировать все фичи, которые предлагаются в рамках этих функциональных требований. Они выставляют в том числе метрики качества к тому, как эти фичи должны быть в целевом состоянии реализованы.
Сколько клиентов сейчас эксплуатируют вашу ERP-систему?
Коммерческое внедрение нашего продукта началось с конца 2022 года. У нас два клиента эксплуатируют систему. Помимо этого, два проекта в пилотной стадии. Наш продукт можно пилотировать с понятными критериями приемки, в том числе на нашей инфраструктуре, заранее определенное количество времени, с принятием решений о дальнейшем внедрении. Продукт можно пилотировать в том числе на особенностях бизнес-процессов или данных потенциального заказчика. Соответственно, у нас два клиента на эксплуатации и два пилота.
С какими системами вы планируете интегрировать вашу ERP-систему?
Что я здесь могу подсветить? Мы точно сохраним практику интеграции нашей системы с классом решений «1С». Также мы сейчас находимся в процессе импортозамещения нашего продукта и понимаем, что на некоторые модули, самые популярные – это ресурсное планирование или проектное управление, – я думаю, имеет смысл написать собственное API, что для дальнейшей интеграции с другими российскими платформами будет максимально эффективно. Например, мы сможем интегрировать с помощью API модуль ресурсного планирования с другой российской системой по управлению проектами, забирая данные о плановых или фактических метриках и отдавая сценарии распределения ИТ-команд. Или мы можем интегрировать наш модуль проектного управления через API – то, как мы ведем метрики, планируем и контролируем проект, – с инструментами task tracking, из которых мы бы забрали фактическую эффективность команд на ИТ-проектах и представили через аналитическую систему план-фактный анализ. Я думаю, мы будем развивать подобного рода интеграции.
Что вам дали конкуренты в плане совершенствования ERP-систем? Что они подсказали?
Сложный вопрос. Точно есть вещи у конкурентов, которые мы перенимаем с точки зрения традиционного проектного управления не по гибким методологиям, потому что ИТ-бизнес чаще работает с проектами в формате гибких методологий. Мы смотрим на современную реализацию самых критичных интересных фичей, связанных с традиционным проектным управлением даже в ИТ. Также обращаем внимание на современные платформы по управлению бизнес-процессами (BPM-платформы), чтобы дать больше удобства бизнес-пользователям, которые не привыкли к интерфейсам айтишников, чтобы улучшить их user experience. Вот что чаще всего мы подсматриваем у конкурентных решений.
Сколько кросс-функциональных команд вы создали и как они взаимодействовали в процессе создания вашей ERP-системы?
У нас две постоянные кросс-функциональные команды, которые взаимодействуют друг с другом. Самое основное, что у нас есть команда, которая работает над текущей эксплуатацией продукта. Потому что, опять же, мы сами являемся клиентами своего продукта и пользователями его. Одна команда сформирована для эксплуатации и поддержки технического качества продукта. Вторая команда – продуктового типа, более ориентированная на сопровождение и адаптацию клиентов, развитие функциональности продукта. Особенно если мы говорим про «пилоты» с потенциальными заказчиками. Отдельно мы можем создавать команду, тоже кросс-функциональную, которая будет внедрять продукт уже у заказчика, на его данных и бизнес-процессах. Наша система очень гибкая. Часто приходят запросы на кастомизацию под некоторые особенности бизнеса наших заказчиков. Соответственно, лучше выделять отдельную команду. Она может быть кросс-функциональной с использованием специалистов из текущих команд, которые уходят на внедрение и адаптацию продукта под клиента. У каждой команды есть руководитель проекта. В продуктовом офисе происходит связь между тем, как работают команды непосредственно в своей зоне ответственности, и как это влияет на продукт. Сверяем часы по направлению движения продукта, по его развитию и дальнейшим задачам отдельно с владельцами продукта через инвестиционный комитет. С горизонтальными и вертикальными коммуникациями у нас не возникает проблем.
