Монополия на стандарты, или Мифы о типовых решениях

Существующие представления о типовых решениях в области автоматизации управления, которыми руководители предприятий руководствуются при выборе ПО, зачастую приводят к ошибочному выбору. Мы рассмотрим здесь некоторые из этих представлений.

Сопровождаемость типового решения – на что стоит надеяться?

Считается, что типовые решения для автоматизации от крупного вендора надежнее, т.к. сопровождаются известной компанией. Качество функционала гарантировано, партнеры поставщика обеспечивают качественное внедрение… Поэтому одним из положений стратегии автоматизации часто является намерение использовать универсальные решения крупного вендора, без каких-либо альтернатив. Пиком идеализации раскрученных поставщиков является политика выбора систем автоматизации только от западных вендоров. Но правильно ли это на самом деле? Если не так, то где проходят границы, за пределами которых это не так?

В действительности, вендор во многих случаях сам не занимается внедрениями, выполняя лишь разработку и продвижение программного продукта. В таком случае поддерживать выбранную предприятием систему будет другая компания, выполнившая внедрение, и только от нее будет зависеть дальнейшая жизнеспособность программного решения, а значит, и бесперебойность бизнес-процессов предприятия. Почему?

Изначально необходимо определиться с тем, что подразумевается под «Сопровождением системы от поставщика».

Со стороны компании-внедренца и собственной ИТ-службы обеспечивается:

• Развитие системы, наращивание функциональности в соответствии с новыми требованиями.
• Исправление ошибок, допущенных при выполнении доработок.
• Загрузка новых версий типового решения, исправлений ошибок и адаптаций к изменившимся требованиям к регламентированному учету от разработчика решения (вендора). При этом выполняется интеграция в новую версию типового решения всех выполненных доработок на внедрении. Со стороны основного вендора обеспечивается загрузка новых версий платформы.

В качестве дополнительного тезиса необходимо подчеркнуть, что внедряемая на предприятии система будет состоять из двух независимых составляющих:

А) Платформы разработки, своего рода «операционной системы» или «программного языка», в которой функционируют прикладные решения (программы), написанные на этой платформе. На любой платформе может быть написано множество прикладных решений.

Б) Собственно прикладного решения (программы), работающего на данной платформе.

Соответственно, сопровождение также делится на две задачи: (А) обновление платформы и (Б) обновления типовых решений. Эти процессы независимы и могут выполняться параллельно, за некоторыми исключениями, когда, например, очередная версия программы использует новые возможности новой версии платформы.

На практике у заказчика крайне редко возникают проблемы с сопровождением платформы. Фундамент системы разрабатывают и сопровождают компании-гиганты, имеющие колоссальный интеллектуальный и финансовый потенциал. Отсутствие проблем во многом объясняется и тем, что платформа для всех потребителей – одинакова. У вендора не возникает необходимости при обновлении платформы вникать в особенности бизнес-процессов всех клиентов. Платформу можно обновлять всегда при выходе ее новой версии, и это никак не связано с тем, какая программа (типовое решение) работает на предприятии. Подобно тому, как, получая обновление операционной системы через Интернет, пользователь не беспокоится за работоспособность остального программного обеспечения, установленного на компьютере. Обновление платформы – несложная процедура, не имеющая чаще всего никаких побочных эффектов.

Все программы, написанные на некоторой платформе, абсолютно равноправны в плане сопровождения этой платформы от основного вендора. При обновлении платформы для заказчика не будет никакой разницы, какую программу он использует.

Далеко не так однозначна ситуация с сопровождением типовых решений (программ), написанных на прикладных платформах (рис. 1). Только в том случае, когда бизнес-процессы предприятия соответствуют типовым моделям, заложенным в программе, заказчик может надеяться на минимальные доработки решения при внедрении и, соответственно, сохранение полноценной поддержки разработчиков программы. Если же компания-внедренец, осуществлявшая проект на предприятии, выполнила серьезные доработки программного продукта под требования бизнес-процессов заказчика, такой программный продукт по понятным причинам не может полностью поддерживаться вендором. В этом случае предприятие сможет получить поддержку только от компании, выполнившей доработки.

Причина этой проблемы технологическая и кроется в том, что модифицированный в ходе внедрения документ, справочник, процедура или регламентный расчет может быть изменен поставщиком решения в очередной версии. Для подгрузки обновления от вендора будет необходим анализ совместимости внесенных доработок и новой версии с последующим ручным переносом программного кода из новой версии таким образом, чтобы не затронуть доработки. Такой перенос — трудоемкая задача и потенциальный источник ошибок. А цена ошибки в системе, интегрированной в бизнес-процессы – остановка этих бизнес-процессов.

Миф № 1. Все крупные вендоры поддерживают свои типовые решения даже после доработок в процессе внедрения

Миф, стоивший многих разочарований и обманутых надежд не одной сотне клиентов. Предприятие имеет право на получение обновлений от разработчика, но на деле оказывается, что решение сопровождает не главный разработчик, а кучка местных «умельцев», от которых предприятие попадает в полную зависимость. И хуже всего, если носитель знаний о вашей системе – это один человек (т.н. «незаменимый специалист»). А ведь он может уволиться и исчезнуть из поля вашего зрения. Придется искать новых специалистов, которым будет интересно вникать во все нюансы ваших доработок.

Если гора не идет к Магомету, то Магомет идет к горе (восточная мудрость)

В последнее время все настойчивей звучит требование потенциальных клиентов – внедрять типовое решение с минимальными доработками. Заказчики, наученные горьким опытом своих коллег по рынку, готовы менять свои бизнес-процессы в угоду модели, реализованной в типовом решении, вместо того, чтобы перерабатывать типовое решение под свои требования. Таким образом, руководство предприятий надеется избежать последствий снятия с сопровождения основным вендором и полной зависимости от внедренца. И, в первую очередь, эта тенденция относится к компаниям, не имеющим собственной ИТ-команды, способной гарантированно обеспечить сопровождение модифицированного типового решения в случае отказа в сопровождении со стороны вендора и внедренца.

Итак, если нежелательно дорабатывать типовое решение под специфичные бизнес-процессы – значит, надо бизнес-процессы приближать к типовому решению. Как же обстоит дело на практике, насколько удается избегать глубоких доработок при внедрении типовых решений?

Ответ на этот вопрос будет разным для разных компонент (контуров) комплексных систем автоматизации учета и управления. В контурах регламентированный учет, казначейская система, бюджетирование, консолидация как правило реализованы типовые бизнес-модели, которые достаточно типичны для разных предприятий. Особенно это касается регламентированного учета, требования которого стандартны для всех.

Гораздо более вероятны доработки, если предприятию требуется не только система учета, но система управления (например, управления продажами, производством, закупками), интегрированная в реальные бизнес-процессы и работающая в режиме реального времени.

Но почему бы не изменить бизнес-процессы предприятия так, чтобы они сошлись с типовой моделью, реализованной в типовом решении?

Ответ таков. Требования к функциям регламентированного учета у разных предприятий схожи, поскольку регламентированы для всех одинаково государством, поэтому в данной области проще всего удовлетворить потребности множества разных предприятий одним типовым решением. Что и подтверждается на практике – бухгалтерский учет в типовых решениях при определенной настойчивости внедряется без проблем. Но если речь идет об автоматизации функций управления, то они не регламентированы для всех общими регламентами, положениями по бухгалтерскому учету, письмами Минфина и ФНС, есть лишь некоторые общие закономерности и модели, общая логика построения бизнес-процессов управления (Рис. 2). Из-за того, что существует множество различных точек зрения на подходы к управлению, модели бизнес-процессов могут быть принципиально разными даже для схожих предприятий, не говоря уже о предприятиях разных отраслей. Модель деятельности, принятая на предприятии, часто заключает в себя индивидуальные особенности, которые формируют базовые конкурентные преимущества организации. Реструктурирование и переориентация деятельности под шаблоны типового решения может привести к потере этих конкурентных преимуществ, что принципиально неверно.

Миф №2. Если функционал и модель бизнес-процессов в типовом решении не соответствует сложившейся модели на предприятии, то легко можно скорректировать бизнес-процессы предприятия, чтобы они соответствовали модели, заложенной в типовом решении.

На деле — вероятность доработок тем выше, чем уже функциональность типового решения, чем меньше возможностей гибкой параметрической настройки модели бизнес-процессов в типовом решении (т.е. без привлечения программиста) под модель управления предприятия. Кроме того, на этапе выбора системы сложно точно определить объем доработок — все выясняется лишь при опытной эксплуатации. Внедренные однажды системы имеют тенденции развиваться, подстраиваясь под новые потребности бизнеса, расширяются рамки автоматизации…

Огласите весь список, пожалуйста… Что делать?

Как поступить руководству крупного предприятия, если комплексная автоматизация стала фактором выживания на рынке, а риски значительных финансовых потерь при внедрении универсальных типовых решений слишком высоки в силу обозначенных выше причин?.

Путей действия может быть два:

• Принять решение о выборе системы и команды внедренцев по идеологическим или политическим соображениям, по субъективно-внутренним ощущениям. Это, естественно, не самый лучший вариант.
• Выбирая систему принять во внимание весь спектр предложений, провести тщательный анализ и сопоставить объективные «за» и «против» каждого варианта. Только в этом случае предприятие получит реальный шанс сделать правильный выбор.

При анализе присутствующих на рынке предложений, помимо варианта доработки универсальных решений от крупных вендоров, можно выделить отдельный сегмент программных продуктов – специализированные отраслевые решения. Характерный пример: на платформе 1С одним из таких заметных отраслевых вендоров является компания ИТРП (http://www.itrp.ru).

Такие специализированные решения чаще всего продвигаются точечными маркетинговыми усилиями в небольших объемах, они крайне эффективны на практике, поскольку поставщик выступает и как специализированный вендор, отвечая как за типовой функционал системы, так и за все выполненные доработки. Но ключевым преимуществом таких решений является именно опыт компании-разработчика, основывающей свои решения на реальном практическом опыте работы с предприятиями конкретной отрасли. Такой опыт позволяет учесть на уровне отраслевого решения различные особенности бизнес-процессов именно данного сегмента промышленности и реализовать необходимый функционал, отвечающий сложным отраслевым потребностям. Подобный специализированный подход принципиально несравним с попытками «натянуть» на уникальные бизнес-процессы предприятия типовой функционал универсального программного решения.

Специализация или всеядность – выбор очевиден!

Преимущества работы со специализированным поставщиком отраслевого решения:

1) Заказчик получает единый центр ответственности за систему, поскольку специализированный вендор является одновременно разработчиком типового отраслевого решения и несет за него полностью ответственность. При этом речь не идет о «клонировании» некоторого базового типового решения.

2) В случае выполнения доработок решения, сопровождать эти доработки будет поставщик, являющийся одновременно внедренцем на проекте.

3) Специализированная компания-вендор, как правило, располагает высококвалифицированными специалистами, полностью отвечающих за результат проекта, поскольку именно оказание качественных услуг и получение позитивного отзыва заказчика является основным инструментом дальнейшего продвижения.

Миф №3. Работа с любым партнером любого крупного вендора – это гарантия качества проекта

На практике – партнера надо тщательно выбирать! Нередко партнеры-внедренцы бывают заинтересованы в количестве и в объеме потока задач больше, чем в качестве их выполнения. В то же время, работая с поставщиком специализированного отраслевого решения, заказчик будет контактировать напрямую с разработчиком, вопросы и задачи решаются наиболее эффективно, а проект с большой долей вероятности станет имиджевым с точки зрения дальнейшего продвижения типового отраслевого продукта.

Итак, вдумчивые руководители, системно подходящие к выбору программного продукта, который ляжет в основу информационной системы предприятия, должны тщательно изучить все имеющиеся на рынке варианты. Развенчав три наиболее популярных мифа, влияющих на решение заказчика при выборе системы, автор статьи попытался помочь руководителям российских предприятий из различных отраслей не совершить ряд типовых ошибок. Только полноценный анализ многих факторов, сбор всей доступной информации поможет принять взвешенное верное решение.

Источники

1. Статья «Как определить эффект от автоматизации?», http://1c-start-project.ru/measure.php

2. Статья «Выбор ERP-системы: два уровня функциональности», http://www.itrp.ru/content/company/public/erp.php.

3. Статья «1С на крупных предприятиях и холдингах — подходы к разделению финансового и оперативного учета», http://www.itrp.ru/content/theory/1c_holdings.php. +