Суть проблемы: При ведении переговоров с заказчиком интегратор может предложить несколько альтернативных способов внедрения автоматизации, которые с той или иной скоростью и эффективностью приведут к конечному положительному результату. Но в силу определенных обстоятельств (например, не составлено подробное техническое задание, не учтены требования всех пользователей и пр.) в процессе работы стороны внедрения могут стать заложниками недопонимания друг друга. В том числе это может быть связано и субъективными представлениями (думали, что это будет работать по-другому) и завышенными ожиданиями (обещали все автоматизировать, а осталось много ручного труда) заказчика.
Для того чтобы избежать указанных проблем возможен вариант внедрения, при котором после сбора первой части требований, заказчику начинает демонстрироваться визуализированный прототип с заказанным функционалом, который он может изучить и при необходимости начать работать. А дальнейшее внедрение осуществляется по нескольким повторяющимся циклам: сбор требований – внедрение – проверка и эксплуатация.
Условно такой подход можно назвать гибким (agile) методом. А метод, как известно, это способ достижения какой-либо цели, - в нашем случае целью является качественное внедрение.
Преимущества метода agile лучше рассматривать в сравнении с другими вариантами внедрения, которые используются на практике.
"Инновационный" подход
Внедрение без подготовки технического задания – это инновационный в кавычках подход, когда требования заказчика собираются в краткой форме и фиксируются в анкете (брифе, опросе или других подобных документах).
Такой подход может практиковаться при типовом пакетном внедрении, при небольших объемах работ или в случаях, когда у интегратора в штате отсутствуют аналитики, которые могут выполнить этот этап работ (поэтому написание технического задания заказчику и не предлагается).
Отсутствие технического задания чревато отрицательными последствиями для всех участвующих сторон, в том числе, потому что нет четкого плана, по которому должна быть достигнута основная цель - качественное внедрение.
Исходя из указанного, применять "инновационный" подход крайне не рекомендуется.
Классический подход
При классическом подходе внедрение осуществляется поэтапно, примерно в следующей последовательности:
● подготовка технического задания (разной степени подробности в зависимости от потребностей);
● базовые настройки модуля CRM;
● автоматизация действий в модуле CRM (в первую очередь бизнес - процессов);
● настройка других специальных модулей;
● интеграции со сторонними сервисами;
● обучение пользователей и техническое сопровождение.
При этом подготовленное на первом этапе качественное техническое задание является самостоятельным продуктом, с которым заказчик может обратиться к любому выбранному интегратору.
Помимо массы положительных качеств у рассматриваемого подхода имеется и отрицательная сторона, суть которой заключается в следующем.
Сбор у заинтересованных лиц требований к внедрению осуществляется, как правило, когда заказчик не знаком с функционалом и визуальным интерфейсом CRM. Такой заказчик условно еще не мыслит автоматизированным процессным способом управления и категориями баз данных.
Поэтому требования отчасти могут быть изложены формально, "как есть", потому что еще не представляется "как это может / должно быть". Аналитик конечно должен в этом помочь, но он в свою очередь не может досконально знать специфику бизнеса заказчика.
Исходя из этого, собранные условия наилучшим образом представляют понимание сторонами требований к проекту внедрения именно на момент утверждения технического задания. В процессе внедрения такие требования не редко корректируются.
В зависимости от объема изменения в техническое задание и соотвественно в настроенный функционал не всегда осуществляются без дополнительной оплаты, что далеко не способствует укреплению взаимопонимания между заказчиком и исполнителем.
Избежать подобные ситуации возможно при использовании гибкого метода внедрения.
Но у классического внедрения есть и следующие ключевые преимущества - практически каждый этап может быть самостоятельным (самодостаточным). Например, после подготовки подробного технического задания, заказчик может обратиться к альтернативному интегратору, который продолжит внедрение. Либо после базового внедрения с минимальным функционалом продолжать развивать автоматизацию может и тот интегратор, который ее не начинал.
Agile подход
В сфере IT-технологий agile-лом является набор методов и методологий, которые помогают команде разработчиков программного обеспечения эффективнее мыслить, работать и принимать решения. В том числе гибкий метод предполагает итеративный (циклический) подход к внедрению, постоянное общение с клиентом и готовность оперативно реагировать на изменения в ходе проекта.
К внедрению Битрикс24 гибкий метод может быть применен приблизительно так:
1. С заказчика собираются базовые требования к настройке CRM, которые могут включать:
● описание процессной модели хотя бы на уровне перечня процессов, подлежащих автоматизации;
● архитектурную схему автоматизации по перечню и стадиям воронок лидов, сделок и смарт-процессов;
● состав полей для базы данных компаний, контактов, лидов, сделок и других сущностей;
● административные настройки – структура компании, роли, права доступа и пр.;
● другие необходимые требования.
Все собранные требования фиксируются в техническом задании и утверждаются заказчиком.
2. Собранные требования частично либо в полном объеме внедряются на портале.
3. Настроенный функционал демонстрируется заказчику.
4. Полученные от заказчика корректировки вносятся в техническое задание и в настроенный функционал.
5. Готовятся регламенты и обучаются пользователи.
6. Осуществляется опытная эксплуатация системы непосредственными пользователями.
7. От пользователей получается обратная связь в виде их пожеланий к улучшению работы системы. Такие улучшения анализируются, утверждаются и учитываются при дальнейшей настройке функционала.
После первой итерации сбора и внедрения требований заказчика, собирается следующая часть требований, которая по аналогичному циклу внедряется на портале. Количество циклов регулируется дроблением требований на удобные заказчику части и повторяется до достижения ожидаемого от автоматизации результата.
Использование метода agile при внедрении предполагает достижения следующих результатов:
● изложенные требования практически сразу наглядно визуализируются в настройках Битрикс24;
● заказчик постепенно расширяет свое знакомство с функционалом системы;
● при постановке новых требований заказчик начинает мыслить категориями изученного функционала и соответственно может свои пожелания формулировать корректней и разговаривать с интегратором на одном языке;
● заказчик переосмысливает видение своих процессов в свете их будущей автоматизации;
● имеется возможность максимально затратить усилия и средства на приоритетные функции и минимизировать / исключить расходы на второстепенные, - то что изначально казалось значимым, но факту может быть сделано в последнюю очередь;
● в техническом задании фиксируются окончательные (в идеале) требования к автоматизации;
● происходит параллельное обучение будущих пользователей системы;
● в зависимости от специфики каждого внедрения может иметься и ряд других существенных преимуществ.
Еще не маловажное преимущество – оценивается и соответственно оплачивается не определенный этап внедрения, а объем работы, который исполнитель выполняет практически на глазах заказчика. При таком подходе отсутствует необходимость наперед оценивать предстоящую работу, потому что оплата осуществляется по факту выполненной работы по отработанным часам (либо отрабатывается полученная предоплата) и заказчику регулярно демонстрируется достигнутый результат.
Но у описываемого метода есть и побочные эффекты, - на первых итерациях заказчик получает и какое-то время эксплуатирует не донастроенную систему. В определенных случаях это может вызывать у него дискомфорт, потому что, например, на руках нет полноценного технического задания или есть сомнение что исполнитель доведет начатое дело до конца и пр. Но эти сомнения могут и не возникать если между сторонами налажены доверительные отношения, которые построены на добросовестном выполнении взаимных обязательств, либо когда исполнитель уже выполнял для заказчика какие-либо услуги и доказал свою компетентность и порядочность. В любом случае к этому необходимо стремиться.
Подытожить применение к внедрению Битрикс24 метода agile можно следующим:
● исполнитель, действуя итеративно и постепенно может обрабатывать требования по частям и дожидаться ответной реакции заказчика, прежде чем приступать к следующему этапу;
● наилучший способ минимизации разрыва ожиданий участвующих сторон - это организация частых точек контакта исполнителя с представителями заказчика;
● корректировки заказчика на начальном этапе внедрения стоят гораздо дешевле, чем внесение исправлений в уже настроенную автоматизацию;
● очередная часть требований может быть ровно такого объема, который необходим для завершения логического этапа внедрения;
● также имеется значительное количество других преимуществ.
Практический кейс применения гибкого подхода
Заказчику - крупной компании по ремонту дорожно-строительной техники была оказана услуга по подготовке предпроектного анализа процессов для целей внедрения автоматизации на базе корпоративного портала Битрикс24.
Для того чтобы очертить границы процессов непосредственно подлежащих автоматизации, было осуществлено верхнеуровневое описано 18 производственных процессов "как есть" и "как должно быть", а также схематично представлены связи этих процессов между собой.
По каждому процессу были даны рекомендации его по способу автоматизации. Был составлен общий план внедрения (дорожная карта) разделенный на этапы, а также было рекомендовано с какой группы процессов эффективнее начать комплексную автоматизацию, то есть определена точка приложения усилий.
При применении классического подхода внедрения следующим шагом должен был бы быть этап подготовки подробного технического задания. Для 18 процессов это достаточно объемный документ, корректно оценить точную стоимость которого без ошибки не представлялось возможным. Иными словами, если бы техническое задание необходимо было написать от начала до конца, то исполнитель оценил бы эту работу с перестраховкой в большую сторону, что по итоговой стоимость маловероятно подошло бы заказчику.
По инициативе исполнителя с заказчиком была достигнута договоренность о том, что внедрение будет осуществляться по гибкому варианту, который будет включать:
● интервьюирование представителей заказчика для сбора подробных требований к частям первого внедряемого процесса (в качестве которого был выбран главный процесс оказания услуг потребителям);
● фиксацию собранных требований в техническом задании;
● настройку портала по согласованным требованиям;
● сдачу этой части работ заказчику и получение обратной связи.
Остальные процессы были внедрены по аналогичному принципу.
Оплата услуг исполнителя осуществлялась по следующему циклическому алгоритму:
● получение предоплаты;
● фиксация в акте перечня выполненных работ и затраченного времени;
● закрытие предоплаты отработанным временем.
После указанных действий исполнитель получал очередную часть финансирования и работы по внедрению продолжались.
По итогу был достигнут желаемый результат - качественное внедрение. При этом в процессе внедрения были использованы все преимущества гибкого подхода.