Файл: Управление процессом реализации изменений и нововведений (Причины и необходимость управления изменениями).pdf

Таким образом, принимая во внимание что все описанные обстоятельства подходят под критерии выбора в пользу Agile, проект предлагается разрабатывать по методу Scrum.

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

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

Чтобы иметь возможность корректировать курс по мере продвижения, еще в процессе разработки каждого эпика, в конце каждого спринта созывается совещание (sprint review meeting), на которое приглашаются все заинтересованные стороны, особенно непосредственные потребители разрабатываемого ПО [2, 8].

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

В результате такого тесного взаимодействия риски закончить и сдать эпик, содержащий неподходящий функционал резко снижается [2, 8].

Организация сдачи в эксплуатацию новых версий ПО

Как упоминалось в главе 2, на данный момент у компании есть 86 центров обслуживания клиентов по всей стране, в которых работают более 400 сотрудников отдела продаж.

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

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

Таким образом, весь процесс разработки и поставки нового функционала можно описать следующими шагами:

1. Выбор и оценка очередной части функционала для разработки в соответствии с приоритетами
2. Итеративно-инкрементная разработка в течении приблизительно 12 спринтов (поскольку выпуск новых версий планируется раз в 3 месяца)
3. Выпуск очередной версии в 2-3 центрах обслуживания
4. Приемочное тестирование в течении 1 недели
5. а) успех: внедрение во все центры обслуживания клиентов; б) провал: возврат на доработку и откат к предыдущей стабильной версии
6. Цикл повторяется с 1-ого пункта, за исключением ситуации с провалом новой версии. Тогда сначала дорабатывается эта версия и цикл начинается с пункта 3.

Этапы внедрения изменений в компании

Любое крупномасштабное изменение – это стресс для организации и ее сотрудников.

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

Рассмотрим применение этапов, предлагаемых Коттером [1] и представленных нами в главе 1, в случае с нашим предложением по изменениям. А также опишем способы, по средствам которых планируется избежать самые популярные ошибки на каждом из упомянутых этапов.

Этап 1. Внушение людям ощущения необходимости перемен.

Ошибка: Избыток самоуспокоенности.

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

Этап 2. Создание команды реформаторов.

Ошибка: Неумение создать достаточно влиятельную команду реформаторов.

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

Этап 3. Видение перспектив и определение стратегии.

Ошибка: Недооценка умения формулировать конечные цели.

В нашем случае, конечные цели четко определены и сформулированы в 3-х пунктах. Задачи измеримы и определены во времени. Стратегия внедрения изменений на протяжении всего проекта определена подходами замены одной системы за другой, а также процессом поставки новых версий ПО.

Всякий раз, при возникновении спорной ситуации при формулировании требований и/или планировании действий, команда реформаторов может задавать себе 3 вопроса, ответы на которые будут определять, действуют ли они в направлении достижения поставленных целей или нет:

1. упростит/ускорит ли это процесс продажи?
2. удобна и интуитивно понятна ли эта функция?
3. способствует ли это изменение повышению продаж?

Этап 4. Пропаганда новой концепции будущего.

Ошибка: Отставание пропаганды видения в 10, 100 и более раз.

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

Этап 5. Создание условий для широкого участия сотрудников в преобразованиях.

Ошибка: Позволить препятствиям блокировать новое видение.

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

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

Этап 6. Получение скорых результатов

Ошибка: Отсутствие ощутимых быстрых успехов.

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

Этап 7. Закрепление достигнутых успехов и углубление перемен.

Ошибка: Преждевременное празднование победы.

Вероятность совершения этой ошибки достаточно велика, по той же причине, по которой низки вероятности совершения ошибок 5 и 6. Быстрое получение результатов может создать ложное впечатление победы и:

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

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

Этап 8. Укоренение изменений в корпоративной культуре.

Ошибка: Изменения не укореняются в корпоративной культуре.

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

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

Проверка вероятности успеха в реализации проекта изменений

Проведем проверку вероятности успеха по модели DICE, предложенной Г. Сиркином, П. Кинаном и А. Джексоном в статье «Проблемы управления изменениями» [3], описанной в главе 1.

D (duration)­ продолжительность. Применение Scrum дает нам возможность уменьшить время между контрольными точками в случае с готовым к поставкам функционала до 3-х месяцев, а на уровне отдельных функций – до 2-х недель. Это дает нам возможность оценить данный показатель в 1 балл.

I (integrity) профессионализм. Как уже упоминалось, команда разработчиков и реформаторов уже сейчас достаточно слаженная и зрелая, что позволяет нам и данный жесткий фактор оценить в 1 балл.

C (commitment) приверженность. Разделяется на два под-фактора – C1, это приверженность высшего руководства и C2, это приверженность сотрудников подразделений, в которых проводятся изменения. Приоритет изменений в данной сфере в компании очень высок, а уровень заинтересованности линейных руководителей максимален. Однако, учитывая возможные риски, описанные на этапах 7 и 8, мы оценим данные показатели в 2 балла каждый.

E (efforts) усилия. Дополнительные усилия для персонала из бизнес отделов сведены к сотрудничеству с командой разработки в роли заказчика. А стратегия внедрения организована таким образом, что, внедряя новый инструмент, обязательно убирается один из старых. Таким образом дополнительные усилия со стороны сотрудников отдела продаж сведены к минимуму. Для команды разработчиков же, этот проект будет основной деятельностью, а не дополнительной работой. Данное обстоятельство дает нам возможность оценить фактор усилий в 1 балл.

Подставив оценки в формулу расчета, получаем:

DICE = D + 2I + 2C1 + C2 + E = 1 + 2 +4 +2 + 1 = 10

Показатель DICE данного проекта <14, что означает, что он попадает в «Выигрышную зону» и имеет очень высокие шансы на успех.

Выводы

Предложенная концепция разработки внедрения реформ в процесс организации продаж решает те проблемы, которые были выявлены во время анализа текущего состояния компании и работы отдела продаж.

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