Классические ошибки заказчиков IT-решений

Сергей Волков,
руководитель компании Start IT Up

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

Автоматизация хаоса

Начну с очевидной ошибки – внедрение информационной системы без измеримых и понятных целей, без четкого понимания «зачем все это нужно». Если вы решили пропустить абзац под предлогом «Ну, это и так понятно!» – не спешите. Множество IT-проектов проваливается именно по этой причине.

Как это бывает? Участники рабочей группы проекта с умным видом оперируют словами «эффективность, совершенствование, бизнес-процессы, трудозатраты». Но никто не может объяснить, при каких результатах проект можно считать успешным. Хорошо, если цели хоть расплывчато, но определены изначально и понимаются одинаково каждым участником. Гораздо чаще все понимают, что нужно делать здесь и сейчас (срочно! горит!), но никто не видит картины целиком и не знает «А что хотим получить на выходе?».

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

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

Хочу все и сразу!

«Нет, я не могу допустить, чтобы мы начали использовать полуфабрикат, все указанные в ТЗ функции важные! Все должно быть реализовано на первом этапе!» – если так начинается проект, обычно ничем хорошим он не заканчивается.

Классические последствия настаивания на полном функционале в первой же версии программного обеспечения:

• Превышение бюджета, так как пользователи, начав использовать систему, обнаружат, что многое не учтено и требует доработки. А дополнительные требования исполнители будут реализовывать за дополнительную же плату.
• До 50% функций из технического задания не используется сотрудниками. Впоследствии выясняется, что они попросту не нужны, и деньги потрачены впустую.
• Сроки проекта превышены почти вдвое: сначала делали по техническому заданию, потом начали переделывать. А за время реализации изменились внешние условия – нужно опять перепроектировать систему, срочно добавлять новые функции.

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

Иначе получится действительно «ракета»: один выстрел, дальше остается только смотреть, попадет она в цель или нет. По опыту большинства IT-проектов – не попадет. С первой попытки, без регулярного корректирующего управления внедрением, дополнений и доработок – очень вряд ли. Часто на прояснение задач требуется больше времени, чем некоторые заказчики хотят выделить на весь проект в целом.

Перед стартом проекта важно понимать следующее:

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

2) Не допускайте составления ТЗ на полномасштабное переписывание программы, в котором игнорируются стандартные функции и алгоритмы, а вместо них «изобретается велосипед». Доверьте задачу составления ТЗ профессиональным консультантам. Например, 1С – очень гибкая платформа, но часто именно простота внесения изменений в исходный код является причиной провала внедренческих проектов. Программистам проще выполнить ошибочные задачи, чем вникнуть в их суть и предложить альтернативные, более удачные решения.

3) Не экономьте на обучении сотрудников: от того насколько они разбираются в возможностях и алгоритмах программы, зависит окупаемость внедрения и получаемые преимущества.

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

Я плачу деньги, что еще от меня нужно?

Зачастую руководители и топ-менеджеры компании заказчика считают, что успех проекта зависит только от исполнителей IT-подрядчика. Но это далеко не так. Для получения результата требуется дисциплина и активное участие заказчика в организации процесса, контроля результатов, оперативного принятия решений.

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

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

Классическая смешная картинка про внедрение IT, которая иллюстрирует совершенно несмешные проблемы

Дайте программиста, задачу я сам поставлю

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

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

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

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

Главные риски «ручного» управления IT-разработкой или внедрением менеджерами, далекими от IT:

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

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

Программный код сам по себе не решение, даже если он работает исправно. Директивы со стороны бизнеса тоже не решение, даже если они адресованы IT. Решением является только пересечение IT и бизнеса. Поэтому экономить на разработке IT-решения – опасная политика. Можно получить формально готовые результаты, которые на практике окажутся неработоспособными или бесполезными.

Редактор рубрики «IT для бизнеса» – Сергей Соловьев