Файл: Управление процессом реализации изменений и нововведений (Причины и необходимость управления изменениями).pdf
Добавлен: 12.03.2024
Просмотров: 34
Скачиваний: 0
СОДЕРЖАНИЕ
Теоретические основы управления изменениями
Причины и необходимость управления изменениями
Выбор метода разработки и внедрения изменений
Анализ текущего состояния организации
Предложение по разработке и внедрению изменений
Организация сдачи в эксплуатацию новых версий ПО
Этапы внедрения изменений в компании
Таким образом, принимая во внимание что все описанные обстоятельства подходят под критерии выбора в пользу Agile, проект предлагается разрабатывать по методу Scrum.
Предлагаемая длительность спринта – 2 недели. Общий объем работ предлагается разбить на крупные части – так называемые «эпики». Каждый эпик будет включать все работы по интеграции в единый интерфейс одной из существующих систем. Таким образом можно будет сдавать в использование новые части готового функционала, параллельно убирая систему за системой, и улучшить показатели уже с первой версией нового программного обеспечения, задолго до полной сдачи всего проекта.
Поскольку первую версию планируется поставить через полгода с начала работ, то первые сдвиги в результатах можно будет наблюдать уже спустя 7 месяцев со старта проекта.
Чтобы иметь возможность корректировать курс по мере продвижения, еще в процессе разработки каждого эпика, в конце каждого спринта созывается совещание (sprint review meeting), на которое приглашаются все заинтересованные стороны, особенно непосредственные потребители разрабатываемого ПО [2, 8].
На совещании команда разработчиков демонстрирует результаты за последний спринт, и заказчик имеет возможность оценить насколько то что сделано соответствует его ожиданиям, а также внести коррективы. Разработчики, в свою очередь, получат возможность услышать и лучше понять своего заказчика и вовремя исправить и/или добавить функционал.
В результате такого тесного взаимодействия риски закончить и сдать эпик, содержащий неподходящий функционал резко снижается [2, 8].
Организация сдачи в эксплуатацию новых версий ПО
Как упоминалось в главе 2, на данный момент у компании есть 86 центров обслуживания клиентов по всей стране, в которых работают более 400 сотрудников отдела продаж.
Чтобы максимально снизить риски, связанные с внедрением нового программного обеспечения, установку новых версий функционала предлагается проводить пошагово.
По завершении нового эпика или при готовности к поставке новой части функционала в уже установленной системе единого интерфейса, обновления происходят не сразу во всех центрах обслуживания. Сначала они устанавливаются в 2-3 центрах, и сотрудники этих центров обслуживания в течении одной недели работают с новой версией. Если в течении этого времени система стабильна и нет неприемлемых неполадок, то новая версия устанавливается уже во всех центрах обслуживания компании. В противном случае – все изменения отменяются и происходит откат к предыдущей стабильной версии.
Таким образом, весь процесс разработки и поставки нового функционала можно описать следующими шагами:
- Выбор и оценка очередной части функционала для разработки в соответствии с приоритетами
- Итеративно-инкрементная разработка в течении приблизительно 12 спринтов (поскольку выпуск новых версий планируется раз в 3 месяца)
- Выпуск очередной версии в 2-3 центрах обслуживания
- Приемочное тестирование в течении 1 недели
- а) успех: внедрение во все центры обслуживания клиентов; б) провал: возврат на доработку и откат к предыдущей стабильной версии
- Цикл повторяется с 1-ого пункта, за исключением ситуации с провалом новой версии. Тогда сначала дорабатывается эта версия и цикл начинается с пункта 3.
Этапы внедрения изменений в компании
Любое крупномасштабное изменение – это стресс для организации и ее сотрудников.
Внимательно изучив примеры успешной трансформации Дж. Коттер [1] обнаруживает, что перемены результативны тогда, когда они осуществляются в несколько этапов, разумно расходуя энергию и энтузиазм сотрудников, необходимые для преодоления сил инерции.
Рассмотрим применение этапов, предлагаемых Коттером [1] и представленных нами в главе 1, в случае с нашим предложением по изменениям. А также опишем способы, по средствам которых планируется избежать самые популярные ошибки на каждом из упомянутых этапов.
Этап 1. Внушение людям ощущения необходимости перемен.
Ошибка: Избыток самоуспокоенности.
Неутешительные цифры о времени и качестве обслуживании клиентов, а также отзывы самих клиентов, привели к тому, что системное решение этой проблемы в данный момент является самым приоритетным в компании на всех уровнях.
Этап 2. Создание команды реформаторов.
Ошибка: Неумение создать достаточно влиятельную команду реформаторов.
Ключевые линейные руководители отделов, которым предстоит принимать участие в разработке и внедрении нововведений – одни из инициаторов процесса изменений. Также, многие из этих руководителей работают в компании более 6-и лет и привыкли к слаженной командной работе в решениях комплексных задач. Готовность этих руководителей, имеющих реальное влияние на сотрудников в компании, содействовать предлагаемым изменениям, формулировать требования к новой системе и работать в тесном сотрудничестве с командой разработчиков – залог успеха на этом этапе.
Этап 3. Видение перспектив и определение стратегии.
Ошибка: Недооценка умения формулировать конечные цели.
В нашем случае, конечные цели четко определены и сформулированы в 3-х пунктах. Задачи измеримы и определены во времени. Стратегия внедрения изменений на протяжении всего проекта определена подходами замены одной системы за другой, а также процессом поставки новых версий ПО.
Всякий раз, при возникновении спорной ситуации при формулировании требований и/или планировании действий, команда реформаторов может задавать себе 3 вопроса, ответы на которые будут определять, действуют ли они в направлении достижения поставленных целей или нет:
- упростит/ускорит ли это процесс продажи?
- удобна и интуитивно понятна ли эта функция?
- способствует ли это изменение повышению продаж?
Этап 4. Пропаганда новой концепции будущего.
Ошибка: Отставание пропаганды видения в 10, 100 и более раз.
Применение Scrum дает возможность постоянно, минимум раз в 2 недели, а при необходимости уточнения требований и намного чаще, общаться непосредственно с сотрудниками и руководителями, чьи работу и в целом рабочую жизнь призвана изменить данная реформа. Готовность к изменениям и постоянное внимание к конечному потребителю этих изменений, напоминание о конечной цели, будут повышать мотивацию и готовность персонала к внедрению изменений. Разработчики, в свою очередь, видя результаты своего труда и получая отзывы от реального потребителя, тоже будут поддерживать высокий уровень мотивации.
Этап 5. Создание условий для широкого участия сотрудников в преобразованиях.
Ошибка: Позволить препятствиям блокировать новое видение.
Действия, описанные в этапе 4, также подходят и для этапа 5. Однако, одним из серьезных препятствий на пути реализации предлагаемого проекта может стать неверие некоторых сотрудников в успех намеченного плана, ввиду его обширности, и пропаганда этого своего видения. Также высказываются опасения, что в результате данной реформы количество используемых систем не уменьшиться, а новая система станет просто еще одним интерфейсом для работы, тем самым усложнив и без того не простую работу сотрудников отдела продаж.
Решение в том, что согласно стратегии внедрения изменений, новая система уже в первом применении будет установлена только с заменой минимум одной из существующих систем. А последовательная работа с пользователями и учет их замечаний в процессе разработки, а не в конце, резко снижает вероятность поставки сложного и не удобного программного обеспечения.
Этап 6. Получение скорых результатов
Ошибка: Отсутствие ощутимых быстрых успехов.
Даже если проект на будет реализован в полной мере согласно начальному плану, ввиду изменения внешних и внутренних обстоятельств, он все равно уже через полгода с начала разработки начнет приносить пользу. А согласно стратегии внедрения, последующие ощутимые результаты будут поставляться каждые 3 месяца.
Этап 7. Закрепление достигнутых успехов и углубление перемен.
Ошибка: Преждевременное празднование победы.
Вероятность совершения этой ошибки достаточно велика, по той же причине, по которой низки вероятности совершения ошибок 5 и 6. Быстрое получение результатов может создать ложное впечатление победы и:
- затормозить дальнейшую разработку, с целью перераспределения ресурсов для решения других задач
- высвободившиеся в результате улучшений ресурсы начинают загружаться дополнительной работой, и в скором времени сотрудники вновь оказываются перегружены второстепенными делами и не имеют возможности качественно и быстро продавать.
Решение в том, чтоб не загружать сотрудников дополнительной работой, пока показатели продаж не достигнут намеченных. А также, после достижения намеченных результатов, любое дополнение и изменение в работе отдела продаж предварительно оценивать по тем же критериям, по которым оценивается данный проект. Отвечать на вопросы, описанные на этапе 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-м различным методикам и во всех них выбранная стратегия показала высокое соответствие поставленным целям и вероятность их достижения.