Суть проблемы: При ведении переговоров с заказчиком интегратор может предложить несколько альтернативных способов внедрения автоматизации, которые с той или иной скоростью и эффективностью приведут к конечному положительному результату. Но в силу определенных обстоятельств (например, не составлено подробное техническое задание, не учтены требования всех пользователей и пр.) в процессе работы стороны внедрения могут стать заложниками недопонимания друг друга. В том числе это может быть связано и субъективными представлениями (думали, что это будет работать по-другому) и завышенными ожиданиями (обещали все автоматизировать, а осталось много ручного труда) заказчика.Для того чтобы избежать указанных проблем возможен вариант внедрения, при котором после сбора первой части требований, заказчику начинает демонстрироваться визуализированный прототип с заказанным функционалом, который он может изучить и при необходимости начать работать. А дальнейшее внедрение осуществляется по нескольким повторяющимся циклам: сбор требований – внедрение – проверка и эксплуатация.
Условно такой подход можно назвать гибким (agile) методом. А метод, как известно, это способ достижения какой-либо цели, - в нашем случае целью является качественное внедрение.
Преимущества метода agile лучше рассматривать в сравнении с другими вариантами внедрения, которые используются на практике."Инновационный" подходВнедрение без подготовки технического задания – это инновационный в кавычках подход, когда требования заказчика собираются в краткой форме и фиксируются в анкете (брифе, опросе или других подобных документах).
Такой подход может практиковаться при типовом пакетном внедрении, при небольших объемах работ или в случаях, когда у интегратора в штате отсутствуют аналитики, которые могут выполнить этот этап работ (поэтому написание технического задания заказчику и не предлагается).
Отсутствие технического задания чревато отрицательными последствиями для всех участвующих сторон, в том числе, потому что нет четкого плана, по которому должна быть достигнута основная цель - качественное внедрение.
Исходя из указанного, применять "инновационный" подход крайне не рекомендуется.
Классический подходПри классическом подходе внедрение осуществляется поэтапно, примерно в следующей последовательности:
- подготовка технического задания (разной степени подробности в зависимости от потребностей);
- базовые настройки модуля CRM;
- автоматизация действий в модуле CRM (в первую очередь бизнес - процессов);
- настройка других специальных модулей;
- интеграции со сторонними сервисами;
- обучение пользователей и техническое сопровождение.
При этом подготовленное на первом этапе качественное техническое задание является самостоятельным продуктом, с которым заказчик может обратиться к любому выбранному интегратору.
Помимо массы положительных качеств у рассматриваемого подхода имеется и отрицательная сторона, суть которой заключается в следующем.
Сбор у заинтересованных лиц требований к внедрению осуществляется, как правило, когда заказчик не знаком с функционалом и визуальным интерфейсом CRM. Такой заказчик условно еще не мыслит автоматизированным процессным способом управления и категориями баз данных.
Поэтому требования отчасти могут быть изложены формально, "как есть", потому что еще не представляется "как это может / должно быть". Аналитик конечно должен в этом помочь, но он в свою очередь не может досконально знать специфику бизнеса заказчика.
Исходя из этого, собранные условия наилучшим образом представляют понимание сторонами требований к проекту внедрения именно на момент утверждения технического задания. В процессе внедрения такие требования не редко корректируются.
В зависимости от объема изменения в техническое задание и соотвественно в настроенный функционал не всегда осуществляются без дополнительной оплаты, что далеко не способствует укреплению взаимопонимания между заказчиком и исполнителем.
Избежать подобные ситуации возможно при использовании гибкого метода внедрения.
Но у классического внедрения есть и следующие ключевые преимущества - практически каждый этап может быть самостоятельным (самодостаточным). Например, после подготовки подробного технического задания, заказчик может обратиться к альтернативному интегратору, который продолжит внедрение. Либо после базового внедрения с минимальным функционалом продолжать развивать автоматизацию может и тот интегратор, который ее не начинал.