Обычно IT-разработчики предлагают своим клиентам уже готовые решения по автоматизации бизнеса. И это понятно. Тиражные продукты выгоднее продавать и проще поддерживать. А выгоднее ли их приобретать и эксплуатировать? Далеко не всегда. Типовой функционал тиражных IT-решений усредняет бизнес-процессы. Между тем, рыночные преимущества коммерческих компаний, как правило, базируются на отличиях. Поэтому бизнес всегда ищет способы заточить IT под свои нужды и специфику.
Самый простой и дешевый способ – использовать уже имеющиеся настройки. Но такие настройки тоже типовые, поэтому эффект дают небольшой. Бывает, что крупные (иногда и средние) компании разрабатывают или заказывают с нуля уникальные IT-решения. Это значительно дороже, дольше, порождает новые риски. И нечто среднее между этими двумя полюсами – адаптация тиражного ПО под нужды своей компании, предполагающее минимальную доработку и модификацию готовых IT-решений.
Какие конкретно преимущества дают адаптации? В чем их слабые стороны? На что следует обращать внимание? Чего опасаться? Ехecutive.ru задал эти вопросы экспертам по информационным технологиям. Своим опытом поделились: управляющий компании «Реалтис» Антон Колганов – руководитель с опытом управления IT в крупных бизнес-организациях (на фото справа); генеральный директор компании «Миракл коммюникейшн» Сергей Милохов – специалист с двадцатилетним опытом автоматизации на платформе 1С.
1.Чем отличаются адаптированные решения?
Сергей Милохов: Самое важное отличие – функционал, который работает именно так, как необходимо заказчику. При этом в проектировании не предусматривается разнообразия вариантов, делается только то, что необходимо для качественного обеспечения нужных функций. Иначе доработка получится очень дорогой.
Второй важный момент. У заказчика адаптаций значительно меньше выбор подрядчиков для осуществления поддержки. Он вынужден в первую очередь обращаться к разработчику, который хорошо знаком с нестандартной архитектурой ПО и может быстро продолжить модификации. Это нормально, если сотрудничество идет гладко. Но если полного взаимопонимания между заказчиком и подрядчиком нет, это чревато различными сложностями и дополнительными затратами.
Антон Колганов: Адаптированные решения в бОльшей степени соответствуют требованиям Заказчика, чем типовые продукты и в тоже время меньше стоят по сравнению с полностью заказной разработкой.
Согласен с Сергеем, что в вопросах поддержки адаптированного решения у Заказчика выбор ограничен и смена поставщика всегда сложное мероприятие. Кроме этого, как показывает практика, компания-исполнитель со временем теряет знания и компетенции по адаптированным решениям. Уходят люди, вместе с ними уходят и знания. Это также служит причиной смены поставщика или перехода к самостоятельной поддержке решения.
С. М.: Если речь идет об адаптации типовой конфигурации ПО и адаптация выполнена грамотно, то поддержку можно разделить на две составляющих:
- Поддержка, касающаяся типовых объектов конфигурации.
- Поддержка сделанных доработок.
Грамотная доработка подразумевает, что сохранены не только функции типовой конфигурации, но и возможность её автоматического обновления. В этом случае поддержкой может заниматься специалист невысокой квалификации, а разработчик привлекается только для поддержки в части доработок.
Иногда бывает другой сценарий, когда разработчик вписывает свой код прямо в типовые объекты. Причины могут быть различными: от банальной экономии до желания «привязать» к себе заказчика. В таком случае поддержку на сторону уже не передать, потому что если новый специалист обновит конфигурацию без учета доработок, они перестанут функционировать.
2. Что можно и чего нельзя адаптировать?
А. К.: Адаптировать можно такое ПО, которое для этого предназначено, которое обладает достаточной гибкостью в архитектуре, в которое изначально при проектировании закладывались такие возможности. В противном случае мы получаем разработку «с нуля».
Адаптацию можно проводить в том случае, если изменения в процессной модели ИТ-продукта по требованиям заказчика позволят и в дальнейшем тиражировать ИТ-продукт. Косвенным мерилом может служить наличие возможности у заказчика сменить поставщика решения после адаптации без замены ИТ-продукта.
С. М.: Отказ от адаптации программного обеспечения, как правило, вызван тем, что стоимость доработок может оказаться выше, чем разработка с нуля. А это в свою очередь может быть связано с одной из трех основных причин:
- Внутренняя структура уже имеющегося ПО спроектирована под другие бизнес-процессы. То есть дорабатывать буквально нечего, слишком большой объем работ по переделке.
- Нечитабельность, запутанность исходного программного кода, его низкое качество, непонятная логика, плохая документация, либо ее отсутствие.
- Разработчик IT-продукта изначально хотел исключить вмешательство в код сторонних специалистов и предусмотрел защиту. Это могут быть как юридические, так и технические препятствия, а зачастую все вместе.
3. Когда выгодно адаптировать программное обеспечение?
С. М.: Выгодно, когда бизнес-процессы заказчика вписываются в типовую конфигурацию или небольшая перестройка процесса под возможности программы не принесет ущерба для бизнеса. Яркий пример – «1С:Бухгалтерия 8» (конфигурации 2.0 и 3.0), которая предназначена для ведения бухгалтерского учета. За годы массовых внедрений эта программа была так отшлифована, что в большинстве случаев для гибкой настройки вмешательств в код не требуется.
Однако не все компании могут ограничиться этой конфигурацией. Что логично, потому что ведение бухучета не основной, а вспомогательный процесс. Значит, для углубления автоматизации бизнес-процессов нужна либо доработка, либо приобретение другой специализированной программы, либо разработка с нуля. Последнее – крайний случай: обычно заказчик выбирает между новым IT-продуктом, как есть, и его адаптацией. Здесь важно учитывать перспективу, оценку того на какой срок IT-решения хватит до следующей модернизации. Если типовая конфигурация подходит для использования в ближайшие годы – очевидно, это ответ. Если нет – лучше сразу подумать про доработки.
А. К.: Думаю, для всех типовых бизнес-процессов организации выгоднее применять типовое решение. Это быстрее и дешевле. Примерами служить бухучет и часть процессов по управлению персоналом.
Выбор в пользу тиражного решения также оправдан, если процессы еще не устоялись, хотя и считаются в организации уникальными. Преимущество типового решения в данном случае в том, что оно содержит модель процессов, которая была опробована в других компаниях. Она точно будет работать и, возможно, даже лучше того, что есть на текущий момент у заказчика.
Адаптация выгодна для поддержки уникальных процессов, которые не формируют конкурентное преимущество – сравнительно не дорого и достаточно оперативно получаем приемлемый результат.
Для критичных процессов, для которых играет роль не только сам факт наличия средств автоматизации, но и характеристики этих средств (скорость работы, точность расчетов, наличие уникальных алгоритмов расчетов и т.п.) лучше использовать заказные решения. Но и в этом случае можно рассматривать подход с адаптацией, т.к. на первых порах характеристики таких решений могут удовлетворить заказчика, особенно, учитывая, что адаптацию сделать дешевле и быстрее.
4. Какие риски адаптаций ПО важно учитывать?
А. К.: При адаптации должны учитываться имеющиеся у заказчика ИТ-решения. Необходимо предусмотреть, чтобы адаптация одного программного продукта не привела к перестройке ИТ-ландшафта у заказчика без существенных оснований.
Контроль за изменениями в ИТ находится в зоне ответственности ИТ-руководителя, изменения в процессах – в зоне ответственности функциональных заказчиков. Желательно, чтобы заказчик при проведении адаптации был представлен на нескольких уровнях, например – ЛПР, функциональные заказчики, ИТ-руководитель и конечные пользователи. Это позволит учесть большинство нюансов при проведении изменений.
С. М.: Могу рассказать, как мы снижаем риски заказчиков на своих проектах по адаптациям. Мы учитываем три ключевых аспекта:
- Прозрачность. Всегда стараемся максимально полно и объективно объяснить заказчику плюсы и минусы того или иного варианта, возможные последствия выбора, риски и трудоемкость.
- Безопасность. Она обеспечивается за счет следования стандартам вендора, разработчика платформы. Мы сохраняем максимальное количество типовых функций, обязательно сохраняем механизм обновлений и как можно более полно документируем все изменения, которые вносим.
- Пошаговость доработок. Это означает возможность проверить взаимопонимание с заказчиком, начав с небольшой задачи. Доработки отличаются от разработки под ключ модульностью, тем, что можно менять и добавлять функции постепенно, одну за другой. Если IT-подрядчик настаивает на «оптовой» адаптации, это повод насторожиться.
