Рубрики

Свежие записи

Человеческий фактор во внедрении процессов и инструментов или где лучше приживаются инструменты?

GD Star Rating
loading...
GD Star Rating
loading...




Автор Новичков Александр Николаевич

Где лучше приживаются инструменты? Странный вопрос — конечно там, где есть схожие инструменты и технологии! Может сказать читатель и будет прав лишь отчасти. Если у заказчика есть похожие технологии и инструменты, то зачастую это только мешает, так как психологически, каждый из нас отвергает все новое.

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

  1. Длительность работы с инструментом — наиболее очевидный фактор — чем дольше —  тем больше привыкли, тем сложнее перейти на новое.
  2. Возраст специалиста — это наиболее интересный фактор, который сам по себе абсолютно ни о чем не говорит. То есть при внедрении можно делать небольшую корректировку на возраст, но только вместе с первым фактором можно говорить о существенном влиянии на конечный результат.
  3. Удовлетворенность текущим инструментарием — фактор «а мне и так все подходит» можно назвать блокирующим — он существенно влияет на результат.

Это были объективные критерии, рассмотрение которых было бы неполным без таких мощных субъективных как:

  1. Нежелание переходить на новую технологию, так как она осуществляет более глубокий контроль над деятельностью исполнителя
  2. Элементарное саботирование…

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

 

А пример?

Хочется привести пример из реальной жизни на данную тему.

Итак, имеем компанию, которая пережила череду поглощений. Персонал состоит из специалистов разных компаний. Возраст — абсолютно разношерстный, но превалирует середняк.

Никаких процессов у организации нет. Правда, руководство пребывало в уверенности их присутствия. В какой-то момент времени всем внутри стало понятно, что без процессов и инструментов автоматизации нельзя — компания на себе ощутила все проблемы  хаотичного подхода:

  • Не те сборки отдаются не тем заказчикам;
  • Документирование ошибок ведется вручную;
  • Журнал ошибок в word;
  • метрики не собираются;
  • Планирования нет (вернее есть планы, которых никто не придерживается);
  • Задачи на разработчика вешаются устно;
  • И так далее…

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

Наверное просто необходимо отметить разобщенность отделов ИТ и полную несплоченность команды. А всем известно, что сплоченность команды имеет очень важное значение успешности проекта.

Хаос в чистом виде!

Часть команды решает, что так жить нельзя и решает навести порядок.

Первое и последнее, что сделано — создана самописная система управления изменениями. Сама система являет собой классику кустарной системы — только учет и только запросов одного типа. Управлять из нее реально можно только задачами, причем не маленькими задачками с одним ответственным, а глобальными задачинами, разбитыми по этапам, за каждым этапом закреплен один ответственный и куча соисполнителей, то есть масса владельцев на одну задачу.

Любой перенос сроков любого этапа приводил к ручному переделыванию всеми ответственными сроков собственных этапов.

Отдельно об этапах. Этапы  выстраиваются в некий водопад, где предусматривается возврат не только на предыдущий, но и на любой вышестоящий — как сочтет правильным руководитель этапа. Ясно, что он не всегда прозорливо угадывает, куда именно вернуть (особенно, когда не определены четкие критерии возврата). Ненужно говорить, что после подобной «итерации» ничего не подозревавший владелец другого этапа крайне удивлен тому, что согласованная задачи через три головы вернулась назад.

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

Вернемся к системе управления изменениями — при все порочности система прижилась, так как лучше хоть какой учет вместо никакого… Система жила и росла полтора года.

Настал час внедрения IBM Rational. Заказчик мягко намекнул, что процессы ему выстраивать не надо. Нужно только автоматизировать существующие. Апелляция к логике, осведомленным источникам  и высшим силам не возымела действия! Клиент уверен, что У НЕГО ЕСТЬ ПРОЦЕССЫ, которые надо автоматизировать. Нас продавили только двумя железными аргументами «клиент всегда прав» и «кто платит деньги?». Пришлось взять расписку об ответственности за неуспех и приступить.

Автоматизация УК и УИ (управление конфигурациями и управление изменениями) пошла в жизнь. Внедрение ClearCase прошло без сбоев. Проблем не возникло — так как ничего похожего у заказчика не было, то решение прижилось. Чистое версионное хранилище может вызвать отторжение только неправильной настройкой. В данном случае все было «ок».

ClearQuest же не внедрился… Это, возможно, первый прецедент в  нашей практике когда не внедрилась система УИ даже в беспорядочном процессе.

Устроим разбор полетов: итак, заказчик привязан к существующей системе и не готов не только менять процессы, но не готов видеть иные экранные формы в системе автоматизации. Получилось так, чтобы выполнить проект необходимо на ClearQuest повторить функционал системы заказчика. То есть выполнить весь некорректный процесс но в другой системе — одна мегасущность и куча соисполнителей.

Естественно, что функциональные возможности ClearQuest позволяет сделать все. Мы повторили функционал, как нас и просили. Только в итоге системой пользоваться никто не стал. Получалось, что все огрехи стали еще более очевидны. Заказчик, в свою очередь, принял решение о том, что данная технология ему не нужна.

 

Скрытые (подводные) камни:

Давайте вспомним, что система самописная и развивающаяся… Отдел, разрабатывавший ее сделал максимум возможного, чтобы ее сохранить. Новое здесь никому не нужно… Пусть даже это новое лучше — здесь свои меркантильные интересы.

Отсутствие явно заинтересованного лица. Казалось бы, руководитель кровно заинтересован в результатах выстраивания прозрачной структуры… Но не в этот раз. Здесь руководитель сидел и ждал чуда, ничего для его получения не делая.

 

Итог:

Система развернута и  сдана. Заказчиком мило похоронена…

Потрачена куча времени и ресурсов практически впустую.

 

Грустно? — да!

Неудачное внедрение? — еще как неудачное!

Консультантов на мыло?! – возможно, да, но рамки проекта не позволяли нам действовать.

 

Чем сердце успокоилось…

Самое интересное! История имела продолжение!

Как известно, история идет по спирали, и на более высоком витке мы обычно сталкиваемся с теми же проблемами, но на более высоком уровне. Так и случилось — заказчик взял еще несколько проектов, нанял дополнительных людей и сложилось так, что персонал сам устал от свой системы, которая при выросших объемах была неспособна эффективно работать (процесса нет а идеология у системы — порочная). очевидно случилась та революция о которой так долго говорили большевики. Да! Еще сменилось руководство. Новый руководитель как раз желал видеть не учет, а эффективность и прозрачность процесса.

Заказчик снова позвал нас и попросил сделать все так, как мы считаем правильным. И случилось чудо — работа пошла.

Здесь теперь живет порядок.

 

 

Анализ разбора полетов

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

Незаинтересованное руководство — отсутствие политической воли практически всегда — провал проекта. Руководство нужно убеждать и доказывать. Если не получается — проблему надо эскалировать. Если это не помогает — пытаться пойти снизу и убедить специалистов. Потом  общей массой доказать правоту руководству.

Почему ничего не вышло у нас?

Выше нашего руководителя только совет директоров компании — нет возможности эскалировать. Ниже специалисты, которым и так хорошо, а вторая часть разработала схожее решение. Фактор «от добра добра не ищут» сыграл на 100%

Возраст специалистов — в чистом виде у него есть влияние, но не пагубное. То есть человеку можно объяснить и несколько раз показать. Но в совокупности с отсутствием политической воли получаем крах.

У нас был ряд проектов, в которых процессы ставились и автоматизировались персоналом, чей средний возраст далеко за 56 лет… И ничего — порядок

Наличие аналогичной  системы — в чистом виде тоже не помеха. Очевидная эффективность ClearQuest перед самоделкой позволит продемонстрировать руководству получение ощутимых результатов. Здесь руководство должно было проявить прозорливость и объяснить своим, что их система помогла в трудное время, но надо идти вперед. Самое главное — продемонстрировать, что разработчики старой не будут сокращены.

В данном случае все этого и боялись…

Внедрение от инструмента — путь в могилу. Нельзя автоматизировать хаос. Любое внедрение должно начинаться с осмысления процессов (с последующим переосмыслением).

В  нашем случае заказчик настаивал только на внедрении инструментов.

Зрелость организации — даже если девять беременных женщин собрать вместе — ребенок родится через девять месяцев. Зрелость и сплоченность коллектива идут рядом. Если организация не сплоченная и незрелая то трудно будет  внедрить инструмент. Здесь нужна воля руководства + процессы + время на их реализацию. Время дозревания.

В нашем случае заказчик дозрел в течении 4-5 месяцев, после того как мы «плешь проели» на всех уровнях, что так нельзя…

Человеческий фактор во внедрении процессов и инструментов или где лучше приживаются инструменты?, 10.0 out of 10 based on 2 ratings
Проверь свою удачу в Азино 777.

Связные и просто интересные записи:

Метки:clearcase, clearquest, ibm, rational, rup, tools, внедрение, инструмент, методология, процесс, фактор, человеческий

12 comments to Человеческий фактор во внедрении процессов и инструментов или где лучше приживаются инструменты?

  • На мой взгляд, ценность данного материала, прежде всего, заключается в том, чтобы показать на реальном примере из жизни, что не всегда виноват тот или иной «неудобный» инструмент, не заинтересованный в результатах своей работы консультант, аналитик или менеджер проекта, даже, быть может, равнодушный к изменениям сотрудник заказчика и т.д. в провале или неуспехе проекта внедрения. Ключевую роль, наверное, играет совокупность факторов, выстраивающих в конечном итоге ситуацию здесь и сейчас. А вообще, плохи не инструменты, плохи те способы, при помощи которых мы пытаемся (или не пытаемся) их использовать…

    GD Star Rating
    loading...
    GD Star Rating
    loading...
  • Василий

    Классический риск менеджмент, а конкретно в данном примере — staff unwillingness. Кроме возможного сокращения, частенько играет особую роль планируемая прозрачность работы на всех этапах проекта. Тут уже сложно будет утаить простои и переделки. Так что не могу не согласиться, немотивированный бизнесом заказчик от ИТ — плохое подспорье в такой работе.
    Ну а если еще добавить и другие риски (коммуникативные, технологические, управленческие и т.д.), другими словами — типичную ситуацию для ИТ-подразделений российских компаний, то у такого проекта было изначально мало шансов. Тем достойнее победа — грамотное полноценное внедрение методик и инструментария вкупе с разработанными заново технологическими процессами.

    GD Star Rating
    loading...
    GD Star Rating
    loading...
  • По поводу прозрачности работы и сокращений интересные мысли высказаны в книге «Цель-3. Необходимо, но не достаточно. Деловой роман о теории ограничений.» Голдратт М.Элия, Шрагенхайм Элия, Птак А.Керол. (http://www.bookmaster.com.ua/sel-3-p-66154.html)

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

    GD Star Rating
    loading...
    GD Star Rating
    loading...
  • [...] Галина on Человеческий фактор во внедрении процессов и инструме…Василий on Человеческий фактор во внедрении процессов [...]

  • Довольно интересная тема для обсуждения.

    GD Star Rating
    loading...
    GD Star Rating
    loading...
  • И правда креатив…супер!

    GD Star Rating
    loading...
    GD Star Rating
    loading...
  • …Материал конечно интересен и в некоторых местах можно поспорить с автором материала…
    Желаю удачи! ;)

    GD Star Rating
    loading...
    GD Star Rating
    loading...
  • Не знаю как вам, а мне нравится! Вот.

    GD Star Rating
    loading...
    GD Star Rating
    loading...
  • [...] ссылкиТолько для вас всегда самое лучшее В основу статьи положены реальные примеры внедрений. В…. Вам точно понравится.Сайт про строительная [...]

  • [...] интересного:Мне порекомендовал В основу статьи положены реальные примеры внедрений. В… знакомый на этом сайте. Я полностью доволен.А еще [...]

  • Âàñèëèé…

    Vladimir…

    GD Star Rating
    loading...
    GD Star Rating
    loading...

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam protection by WP Captcha-Free