Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

1С Предприятие. 4 ключевые проблемы проектов внедрения

1С Предприятие. 4 ключевые проблемы проектов внедрения

Итак. Проект завален. В чем причина?

Причин конечно можно назвать много. На кого не посмотри, явно на причину похож! И разбор полетов можно делать до посинения.

Ключевая проблема в том что внедрением занимаются программисты. Хотя это задача управленческая. Только человек с компетенциями руководителя, способен доводить действия до результатов, вне зависимости от затруднений.

Разбираем…

Для внедрения нужны 3 ключевые роли (моя версия):

руководитель проекта (тот кто добьется результата, может привлекаться со стороны)

программист (специалист знакомый с программой, и тем как выглядят процессы при ее использовании, может привлекаться со стороны)

специалисты по текущим процессам (как правило внутренние сотрудники, желательно поадекватней, хотя грамотный РП выудит нужную информацию даже из пьяного бабуина)

Для внедрения нужны 3 ключевые роли (версия В. Тарасова, © Управление по Макиавелли):

Фанат — тот кто знает как выглядит конечный результат, и не боится вступать в конфлик, защищая идею, если кто-то решил вводит противоречия в проект, пытается все вернуть на прежние места;

Менеджер — тот кто сумеет совместить старые порядки, с новыми, напишет инструкции …;

Крестный отец — тот чья сила обеспечивает движение проекта, тот кто может применять административный ресурс;

В обоих вариантах роли подразумевают лишь роли. Они могут соответствовать одному человеку или нескольким. Важно чтобы они были.

Кроме людей понадобится компьютер, сама программа и листок бумаги :)

Если убрать в сторонку толстые книги по PMI, PM BOK, Agile … Ключевые правила, нарушение которых приводит к провалу проекта. Правила очень простые. Но нарушаются в 99% случаев.

Правило №1. Еженедельные совещание во главе с руководителем проекта (РП). Руководитель проекта задает вопросы, дает задания, с одной лишь целью… выполнить правило №2.

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

Правило №3. Пользователям нужны инструкции. Но инструкции по процессам и функциям, а не объектам и документам программы, кои идут в комплекте. Отличие существенное и их рассмотрим ниже.

Правило №4. Служба технической поддержки, способная решать сложные технические проблемы и находить решение ошибок. Может быть удаленная. Но надежная. Потому если нет поблизости можно купить кого нибудь через Интернет.

А вот теперь подробней по каждому пункту.

По правилу №1. РП это ключевая фигура. Можно нарушить любые правила и испортить все что угодно, но если РП достойный то он вырулит. Но если РП нет или вместо него Чучело, тогда на каждом совещании будем узновать о том что у нас снова что то не так и сроки будут звучть «ну вот еще пару недель и все будет» или «да мы почти закончили, нужно только начать да кончить», или «не знаю сроков, тут много всяких нюансов», а может быть РП обвинит всех во всем, скажет что все дураки, что в провале проекта виноват тот, тот или тот, а он сделал все что мог.

По правилу №2. Отчет это ключ от двери где деньги лежат. В разделе Результаты пишем что было сделано за прошлую неделю, и все те результаты которые достигнуты по ходу проекта. В разделе План пишем те действия которые планируются, ответственные, сроки, на следующий период. В Проблемах пишем какие то затруднения которые приводят к пробуксовке, и ответственных. Это может быть сам РП, программист, пользователь, или служба технической поддержки. Отчет обновляется по итогам совещания. Рассылается проектной группе. И так до следующего совещания. На следующем садимся, проходимся по пунктам, срокам, ответсвтенным. Если срок нарушен, то нужно сделать все возможное, чтобы человеку больше не захотелось нарушать данное им слово. В общем добиваемся того чтобы в следующий раз ставили или более реальные сроки или кровь из носу выполняли те что установили.

По правилу №3. Программа это вторично. Запустить систему можно и без программы. А вот организовать процесс без инструкций это сынок фантастика. Инструкции это основа системы. Но инструкции не те что идут в комплекте с 1С Предприятие. С теми инструкциями можно идти костер разжигать. Пользователям от них толку мало, т.к. эти инструкции написаны программистами для программистов. Книги тоже дают мало пользы, особенно новичкам. Инструкция должна быть написана с точки зрения процессов и процедур. Полный порядок действий, от А до Я с картинками. Плюс условия при которых процесс начинает ветвиться и вилять, все возможные петли. Мол если это тогда вот туда. Такие процессы идут с развитыми продуктами типа SAP, Navision, DIRECTUM, там где культура внедрения развита и есть соответствующая категория специалистов. А вот в 1С этой категории нет и соответственно знаний этих тоже. Есть программисты, которые не в курсе что такое инструкции для пользователей, что такое процессы, что такое ТЗ на внедрение. Они их путают с инструкциями по программе, а также с ТЗ на разработку, думая что это одно и тоже или что то похожее.

По правилу №4. 90% организаций продающих или внедряющих 1С до сих пор относятся к тех.поддержке как к чему то мало важному. Обращения пользователей остаются без регистрации, теряются, забываются, забиваются. Контроля сроков нет. Доверие пользователей теряем в первые же секунды сотрудничества.

Резюме

Не надо учить умные книги и залазить в дебри теорий. Это очень простые правила. Которые нужно лишь постараться выполнить. Я понимаю что найти РП из п.1 в наше время сложнее чем почесать ногой за ухом, но пойдет любой человек с организаторскими компетенциями который сможет выполнить остальные 3 пункта.

Источник

Дополнительные материалы

"Я — Юра Шевчук, музыкант" (с)

Недорасходы — причина провала ИТ-проектов

А у вас есть план провала проекта и отката к предыдущим системам?

Комментарии (10)

  • Аватар

    Котельников Илья [iluha], 01 июля 2011, 08:44

    0
    Статья классная.
    Да, умные книжки читать не нужно, но и правил можно придумать больше.
    Мое мнение - правила работают, только когда они выведены собственным опытом.
    И к Вашим правилам я бы добавил еще:
    5. Всегда подписывайте Договор и ТЗ (хотя бы в произвольной форме) до начала реализации работ - они нужны не для заказчику, а вам.
    6. Руководитель проекта со стороны заказчика должен быть один. Всегда один. Если их получается несколько - остальные понижаются до статуса технических специалистов. Если они не могут принять решение, то это их проблема.

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

      Ханник Максим [maxxannik], 01 июля 2011, 08:59

      0
      Тут такое дело ))
      п. 5 как показывает моя практика часто делается формально. ТЗ высасывается из пальца и надеяться на него как на инструмент проекта не приходится. И тебе такой проект предают уже в запущеном состоянии или заваленном.
      п. 6 тоже учитывая развитость абыкак-менеджмена, доставшегося от СССР, не так то просто добиться.

      в общем п. 5 и 6 конечно же желательны, но не всегда находятся в зоне влияния РП.

      а вот 1 и 4 это всегда зона влияния РП. и мне удалось при помощи этих правил вырулить очень большой проект на 1000 пользователей (сотрудников было еще больше), при том что п.5 и 6 были нарушены ) а также еще куча общепринятых норм управления были просто проигнорированы заказчиком )
      • Аватар

        Котельников Илья [iluha], 01 июля 2011, 09:41

        0
        Про ТЗ я и говорю - оно нужно не заказчику, а вам. Поэтому пишите для себя, потом требуйте от заказчика подпись. Что тут сложного? - только время... Я даже уточню, что именно необходимо написать. В госте на ТЗ к системам автоматизации есть такой раздел - условия сдачи-приемки, т.е. необходимо выбрать правило, по которому будет проходить финальная проверка, а так же указать конкретные задания, которые должна выполнить система или указать правило их возникновения. И указать состав принимающей стороны. На все остальное можно забить.

        А в правиле 1 подразумевается внутреннее совещание только для стороны исполнителя? Если имеется в виду с участием заказчика - не вижу принципиальной разницы с моим правилом 6. Но принципиально важно, чтобы у заказчика решения принимал не совещательный орган, а конкретный человек.

        Ну и раз уж пошла такая пляска - пользователям не нужны инструкции, если они их не читают ;) Как договориться с пользователями о прочтении инструкций, даже если вы их написали? Проблема, которая решается только через адм. ресурс и личное отношение к проекту руководителя. Если никак не закреплять ответственное лицо со стороны заказчика за обучение, то есть риск получить проблемы - это не умозрительное заключение, это проверено на практике. Бывает - напишешь инструкции на все пользовательские процессы в системе страниц на 10 с картинками для каждого АРМ. А все звонки - все равно пойдут в ТП, потому что пользователям тупо "в ломы" читать инструкцию, если ТП нормально работает.

        Большинство вопросов, из-за которых происходит завал проектов - это недофинансирование, низкая компетентность исполнителей и отсутствие разделения зон ответственности. Причем все эти вопросы завязаны друг на друга. Я вот сейчас комментарий написал и у меня даже родилась идея поста! 
         
        • Аватар

          Ханник Максим [maxxannik], 01 июля 2011, 10:20

          0
          Инструкция - инструкции рознь. Вопрос умения. Скажем играть на гитаре можно красивую мелодию, а можно брякать по струнам. Или бывает машина BMW X6, а бывает ОДА-Москвич. В одном случае тебе приятно садиться в машину, а в другом она стоит во дворе, т.к. не приятно.

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

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

          Но если инструкции в норме, то вместо ответа на вопрос, просто говоришь пункт инструкции и следишь чтобы человек делал так как там написано - опля и результат. Пара таких фокусов и пользователи потом сами их читать начинают. В моем понимании нормальная ТП - это когда на вопрос не дается прямой ответ, а дается ссылка на пункт инструкции, который пользователь забыл сделать. Такой принцип позволяет существенно повысить надежность информационной системы, и снизить число обращений в ТП - основная цель ITSM\ITIL.

          Бе бе бе )))
          • Аватар

            Котельников Илья [iluha], 01 июля 2011, 10:42

            0
            хе-хе, вот столкнетесь с преднамеренным саботажем на внедрении тогда и попляшете даже с самыми офигенскими инструкциями...
            Все работает, если пользователи мотивированны использовать систему. Если нет, то тут и песенке конец. Пример:
            К (кассир):    - У нас смена не закрывается. Ваша долбанная 1С опять не дает мне уйти с работы вовремя.
            И (инженер): - Хорошо, давайте посмотрим вместе, что не получается.
            К:                 - Да ничего не получается, она мне все время пишет что-то а чек не выходит.
            И:                 - Так давайте с начала, вы выполняете все, как сказано в инструкции?
            К:                 - Да, я вот тут включил, вот тут вот вошел в Штрих-М, на вкладку...
            И                  - Погодите, ведь это не по инструкции!
            К:                 - Да какая мне разница, я домой хочу!
            И:                 - Ну хорошо, давайте сделаем по инструкции. Открывайте на странице 5, картинку видите, вот с нее нужно начинать...
            К:                 - Да не нужна мне ваша инструкция, вы мне скажите как смену закрыть!

            И в том же духе. Хорошо, объясняем кассиру, как все сделать, заставив его посмотреть в инструкцию. На следующий день - новый кассир. В одном магазине смену могут закрывать 8 человек из 10 работающих. Всего магазинов - больше 15. Каждый день в конце дня шквал звонков. И это на смотря на то, что есть удобная (тут я согласен - удобство это важно) инструкция по конкретной функции конкретного АРМ, причем у продавцов было еще и обучение! На третий день, я как новый ПМ не выдерживаю и естественно собираю директоров магазинов и технического директора. Приезжает только половина. Хорошо, пытаемся узнать у этой половины, в чем проблема. Ответ единый - проблема в 1С, не хотим ее, а хотим старую систему. Хорошо, берем их руководителя - коммерческого директора. А он то и не хочет 1С-ку сам внедрять и смотрит на нее сквозь пальцы, мол - подождем, пока загнется. Но формально не является ответственным за ее внедрение, а входит в совет, состоящий из владельцев конторы, генерального, коммерческого и ит-директора. Каждый раз они спорят и обвиняют друг друга и выясняют кто из них козел.

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

            Бе бе бе )
            • Аватар

              Ханник Максим [maxxannik], 01 июля 2011, 10:55

              0
              Я б не был таким уверенным в том что мне за свои 5 лет опыта и более 100 проектов не пришлось встречаться с саботажем )

              Правда каждый саботаж приходится решать по новому ) но всегда находил тот или иной способ решения )

              Сейчас вот тоже на одном из проектов уперся в уровень зама, который всячески вставляет палки в проект, и почему то генерал ему ничего не может сделать ) ну ничего ) ищем приемы, подходы ) не в первой ))

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

              Психи пользователей это тоже норма. И где то первые 10 проектов я еще терялся при виде таких картин, то сейчас эти психи для меня что то типа восхода и захода солнца. Ну типа естественный порядок вещей на любом более или менее крупном проекте ))
              • Аватар

                Котельников Илья [iluha], 01 июля 2011, 11:04

                0
                Это я все к тому, что правило единого ответственного для меня теперь обязательное. Идеальный интерфейс - такой, что даже инструкции не нужны. А вот со множественной ответственностью в одной точке я больше проект делать не возьмусь. Ну его нах :)
                • Аватар

                  Ханник Максим [maxxannik], 01 июля 2011, 11:09

                  0
                  Это да )
                  У каждого практика своя технология )
                  Кто то играет на барабане, а кто то на баяне )
                  Главное уметь играть красиво, а на чем играть - не суть важно )
          • Аватар

            Ларькин Денис Юрьевич [Vasy911], 10 июля 2011, 18:57

            0
            Согласен  с Максимом, практика когда ТП отслылает к конкретной инструкции или пункту инструкции, очень часто помогает, плюс сокращает время которое тратит ТП на решение инцидента
        • Аватар

          Ханник Максим [maxxannik], 01 июля 2011, 10:25

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

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