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

      Комментарии к записи Классические ошибки заказчиков IT-решений отключены

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

Сергей Волков Финдиректор, Москва

Обладатели бизнеса и топ-менеджеры довольно часто показывают собственный успешный опыт управления с вторых сфер деятельности на 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 для бизнеса» – Сергей Соловьев

Неточности в работе с клиентами IT компаний


К прочтению:

самые интересные статьи, подобранные как раз для Вас: