Аутсорсинг бизнес-систем: pro без contra

Юрий Панченко, заместитель директора Сервисного центра по организации производства компании «Инфосистемы Джет»

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

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

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

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

Лиха беда — в начале

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

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

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

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

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

Адекватная альтернатива

Компании, которые заранее осознают возможные трудности и проблемы, выбирают третий путь: их техническое задание на разработку прикладной системы изначально содержит требования к отчуждаемости. Яркий пример такой компании — «М.Видео». В свое время руководство компании приняло принципиальное решение разделить функции разработки и эксплуатации программного обеспечения.

В данный момент Сервисный центр компании «Инфосистемы Джет», кроме обслуживания ИТ-инфраструктуры «М.Видео», полностью отвечает за информационные системы SAP ERP и Oracle Siebel CRM, включая настройку, мониторинг, администрирование и техническую поддержку. Наши специалисты, принимая от подрядчиков любое доработанное ПО, проводят его тестирование и дают свое экспертное заключение: можно ли внедрять это ПО в «боевые» системы. В случае положительного ответа осуществляется внедрение, после которого за программным обеспечением наблюдают в режиме штатной эксплуатации системы. Если же продукт нуждается в доработке, его отправляют на второй круг. Фактически мы несем финансовую ответственность за бизнес-результат, который покажет прикладная система после появления в ней нового «кирпичика». Такая организация совместной работы очень показательна: она демонстрирует умение «М.Видео» управлять своими информационными системами.

Какие же условия должны быть соблюдены для того, чтобы компания могла передать прикладные системы на аутсорсинг? Необходимо четко определить приемлемое время их простоя. Например, складская учетная система при условии, что каждые полчаса со склада уходит транспорт с грузом, не может простаивать больше 30 минут. Бывают и более жесткие сроки. В то же время аналитическая и финансовая отчетность, необходимая для работы раз в 2–3 дня, может «потерпеть» и несколько суток. Соответственно, четкое понимание сроков ведет к составлению адекватного SLA, точно отражающего конкретные потребности компании. Только определив SLA и актуальные бизнес-задачи, можно рассматривать различные аутсорсинговые предложения: отдать прикладные системы на аутсорсинг целиком или частично, начать с ИТ-инфраструктуры, а затем перейти к рассмотрению вопроса об информационных системах и т. д.

При этом передача функции доработки ПО «на сторону» дает дополнительные преимущества. Компания, конечно, тратит дополнительные средства, но вместе с тем ясно осознает, для каких именно целей нужна доработка, оправданна ли она с точки зрения затрат, в какие сроки будет выполнен проект. В случае если «тюнингом» ПО занимаются свои сотрудники, возникает иллюзия, что можно заниматься этим бесконечно и финансово безболезненно. Главное — продукт часто дорабатывается в соответствии с сиюминутными пожеланиями сотрудников. В результате автоматизация операции, ручное выполнение которой занимает не более 5 минут, может обернуться месяцами работы разработчиков. Их зарплату никто не отменял.

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

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

Контактная информация

Наши сайты: www.jet.su, www.jetinfo.ru. Электронная почта: info@jet.su.

Другие статьи раздела «А вы что... и пальцы загибать за меня будете? — Ага!»