ВНЕДРЕНИЕ 1С:ERP и 1С:Управление холдингом     Главная     Проекты, результаты     Консультации (Новый раздел!!)     Обратная связь. Отзывы, рекомендации    
 












УТ 8.2 & УПП : Управленческий & Торговый учет

Как сэкономить 2 млн. руб. или 20 секретов внедрения проектов "1C"


В данной статье я поделюсь опытом «как сэкономить до 30%» от стоимости проекта внедрения 1С.

Те, кто занимался этими вопросом, знают: сейчас стоимость проекта для предприятия среднего бизнеса составляет около 6 млн. руб.
Таким образом, снизив стоимость на 30% процентов, экономия получается - 2 млн. руб.
Ощутимая цифра. Особенно в условиях экономического кризиса, когда деньги «заметно дорожают».

- Так за счет чего же можно сократить затраты на 30% ?

- Можно ли добиться этого, не затягивая сроки и без потери качества работ ?

- Да, можно. Если следовать проектной технологии и знать некоторые ее секреты.. Надеюсь, что данная статья + мой опыт помогут вам сэкономить до 2 млн. руб. на проектах внедрения 1С.
Контактная информация: +7 (916) 304-16-80, accountit@mail.ru

1. Проектная команда
  • Назначение ген. заказчика
Первое, что необходимо, это – назначение ген. заказчика по проекту.

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

Т.е, например:
  • интерес клиентского отдела - максимально быстро и просто выписывать документы покупателям;
  • интерес бухгалтерии – полно, подробно оформлять и учитываться хоз. операции в соответствии с требованиями ПБУ;
  • интерес финансово-экономической службы – получение аналитической отчетности в соответствии с требованиями руководства, определение маржи, планирование, план-фактный анализ.
Всегда нужно помнить, что «1С» (в первую очередь) эффективна для решения учетно-аналитических задач. И еще более эффективна, для автоматизации регламентированного учета..
  • Т.е если, например, ген. заказчиком вашего проекта выбран главный бухгалтер – это хорошая (понятная) перспектива;
  • Если в рамках вашего проекта автоматизируется внутрифирменный учет (и он отличен от регламентированного), то лучшим заказчиком будет финансовый директор. Чаще всего, фин. дир - влиятельный (коммуникация, интересы руководства) и понимающий «1С» сотрудник. Т.е это - хорошая, понятная перспектива.
  • Если же ген. заказчиком проекта (именно главным..) назначен, например, начальник планового отдела, начальник производства, руководитель по логистике, директор по IT и т.д – то это (скорее) «плохой знак».

Даже, если даже в рамках проекта решается только какая-то специализированная задача (например, складская логистика) и по такой задаче нет непосредственного учета фин. показателей (например для склада – товарный учет), все равно нужно (в итоге), выходить на финансовый учет, а далее – на планирование.

Т.е фин. директор должен сформулировать «какие фин. показатели должны в итоге учитываться» (например, для склада - затраты на хранение, обработку груза и т.д.), и обязательно нужно оценить эффект от автоматизации «в деньгах». Т.е что бы «ценность» получаемы данных была ощутимо выше затрат на них.

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

Итого: правильный выбор ген. заказчика является первым необходимым условием успеха проекта. В противном случае, проект гарантированно потерпит неудачу.
  • Руководитель проекта, подрядчики и прочие исполнители
После выбора ген. заказчика, следующий этап - назначение руководителя проекта, подрядчиков и прочих исполнителей.
Есть две ошибочные стратегии, при выборе исполнителей на проектах 1С:
1. Найти исполнителей: «франчайзи», «консалтеров». Изложить им свои пожелания. Сказать – «сделайте нам все хорошо» и ждать результат.

2. Решить – «делаем все сами». Cоздать IT-отдел, взять 1с программистов… И ждать результат.
Эффективной стратегией является сочетание привлеченных ресурсов и ресурсов собственных.

Логику здесь можно пояснить примерно так: есть сдельная форма оплаты труда, и есть окладная. И прим этом, эффективны сдельно-премиальные и окладно-премиальные.

Еще важно понимать, что на проекте задачи будут разного характера. И оптимизировать затраты можно в зависимости от их характера. Например:
  • Разработка ТЗ, доработка ключевых механизмов конфигурации по ТЗ . Это задачи нормируемые по времени (ТЗ – оценивается). При этом, данные задачи требуют особой квалификации (специализации) со стороны исполнителя.
Такие задачи целесообразно назначать консалтерам, франчайзи.
  • Перенос данных в процессе внедрения. Эти задачи сложно нормировать. При этом, задачи могут выполняться программистами, уже по разработанным ТЗ, под контролем пользователей.
Такие задачи целесообразно назначать штатным 1с программистам. При нехватке ресурсов - привлекать фрилансеров.

Итого: оптимизировать затраты можно за счет привлечения разных подрядчиков (франчайзи), а так же фрилансеров и штатных IT-шников.
И главная сложность в том, что необходимо контролировать, координировать их работу. Распределять задачи по ним.

Для этих целей, на проекте и необходим руководитель проекта.

Если на вашем предприятии есть руководитель по направлению «1с», или этим занимается (и разбирается в этих вопросах!) IT-директор, то руководителем проекта нужно назначать его.

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

Необходимость уделять много времени и усилий проекту – это относится и к руководителю по 1с / IT-директору тоже. Кроме того, необходимо будет хорошо ( :-) ) разбираться в той программе 1С, которая запланирована в основе проекта.

Итого: что бы повысить качество работы над проектом, работать без ущерба текущему процессу (задачам), лучше всего привлечь в проектную команду эксперта по 1с (программиста-аналитика). Такой специалист сможет решать следующие важные задачи:
  • Экспертиза решений, предлагаемых франчайзи, фрилансерами и т.д;
  • Оценка трудозатрат, контроль качества выполнения работ, отстаивание интересов компании в части принимаемых технических решений;
  • Разбор сложный ситуаций, поиск решений, консультирование по 1с при внедрении;
  • Стабильность команды, уход из проекта
Как показывает практика, большой (в т.ч. финансовый) ущерб может принести уход/смена ген. заказчика, руководителя проекта, основных подрядчиков и экспертов.

Причины ухода с проекта бывают разные, но чаще всего они объективные. Т.е те, которые произошли из-за компании-заказчика.
  • Затягивание по срокам проекта;
  • «Уход» от проектной технологии. Пересмотр, не конкретность принимаемых решений;
  • Не качественное/не компетентное руководство.
Обо всем этом нужно помнить, что бы «не потерять» проектную команду.

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

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

Таким образом, очень важно «состыковать» работу всех этих исполнителей, что бы кодирование подчинялась единым стандартам, подходам, «умолчаниям» и т.д.

Для этого, целесообразно подготовит соглашение о кодировании, доводить его до всех программистов и требовать его исполнения.
Аналогичная ситуация, например, с работой аналитиков и способами описания ими бизнес-процессов. Можно привести и др. примеры.
  • Приоритет содержания над формой
Прием (и исполнение) соглашений, регламентов взаимодействия повышает качество работы проектной команды. Однако «увлекаться» регламентированием не следует.

Бесполезно (и даже вредно) усложнять, «заорганизовывать» коммуникации. Сложные, многоступенчатые регламенты не будут исполняться, и будут, скорее, мешать работе.

В конечном счете, руководство должно делегировать исполнителям право наладить взаимодействие «так как это будет удобно им».
Профессионалы всегда найдут для себя рациональные правила взаимодействия. А вместе с делегированием прав нужно делегировать ответственность - по срокам и качеству работ.

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

Руководство проекта обязательно должно вести календарный план и актуализировать его по факту выполнения задач. Т.е. нужно «расписать» этапы проекта, далее задачи укрупнено, далее детально и т.д.

Нужно так продумывать последовательность выполнения работ, что бы «распараллеливать» задачи и иметь «маневр» для корректировок плана, что бы избегать простоя (из-за отклонения по срокам связанных задач).
Другими словами, нужно задействовать программу MS Project и постоянно работать с ней.
  • Оценки, резервы, торги
Что бы запланировать задачу по срокам, нужно оценить ее трудоемкость.
Если вы будете работать с подрядчиками-франчайзи, то обычно процесс оценки трудоемкости (а следовательно, и цена работы) у них отлажен.

Т.е опытный специалист всегда постарается заложить возможные риски по выполнению задачи в ее оценку. Заложить риски – это нормально. Вопрос в том, сколько процентов «в плюс» закладывается.
Нормальная практика + 20 %. Малоопытный специалист может заложить цифру, сильно отличную от этой. Причем для проекта это плохо и в случае завышения (удорожание) и в случае занижения оценки. (сбиваются сроки выполнения)

Менеджер проекта (со стороны франчайзи) так же вполне может перестраховаться или просто необоснованно завысить бюджет. Тем более, если он мотивирован на это экономически.

Так каким же образом проконтролировать оценки, согласовать их c подрядчиками и уменьшить ? (торг :-) ).

Для этого, так же эффективно привлечь эксперта по 1С. Программиста-аналитика независимого от исполнителей. Он сможет дать свою оценку и аргументировать ее для подрядчиков.

Практика показывает: часто стоимость работы можно сокращать на 25-30 %.
  • Deadline;
Крайний срок завершения работы (deadline) – важнейший регулятор, который отличает проектный подход от процесса автоматизации с неясными бюджетами и сроками.

На проекте могут, конечно, да и происходят корректировки по планам, срокам.
Однако обязательно должны быть такие точки deadline, в которые (так или иначе) работу необходимо завершить.

Это можно сравнить с ремонтом в квартире. Как говорится: ремонт нельзя завершить, его можно только остановить.

Очень важно понимать, что и нормальный подрядчик, и нормальный заказчик – оба заинтересованы в том, что бы deadline были.
И задача заказчика – определиться с такими точками на плане проекта, а затем мужественно им следовать.

Теперь, пора подвести некоторые важные итоги. Мы рассмотрели 3 критерия,
гарантирующих выполнение проекта:
  • Создание проектной команды;
  • Организация эффективной работы в проектной команде;
  • Управление сроками выполнения работ.
Иными словами, во всех реализованных (живых) проектах эти критерии были выполнены. И выполнение этих критериев в принципе достаточно, для завершения проекта.
В тех же проектах, в которых хотя бы один из них не был выполнен - такие проекты потерпели неудачу.

И так, будет считать, что все необходимые и достаточные условия для проекта - созданы.
Однако, наша задача глубже, сложнее – сократить (оптимизировать) затраты на проект, при этом не ухудшив его качество, и не растянув сроки.

Как это сделать?

Для этого существуют свои «секреты». Рассмотрим их, начиная с очень важного этапа – «Подготовка к проекту».

4. Подготовка к проекту
  • Что бы «говорить на одном языке»
С разных сторон участники проекта должны «говорить на одном языке», что бы понимать друг друга. А иначе очень затруднительно будет, например, донести свою мысль, понимание проблемы на совместном совещании. Трудно будет понимать, согласовывать проектную документацию и т.д.

«Корень» проблемы не понимания» (а точнее – очень разного понимания вопросов) – большие различия участников (проектной команды) в отношении средства и предмета автоматизации.

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

Штатные сотрудники вашего предприятия, наоборот, знают процессы и особенности «изнутри». А вот средством автоматизации и продвинутыми технологиями, скорее всего не владеют.

Отсюда, собственно, и возникает задача: повысить соответствующие компетенции участников с обеих сторон.
Для ключевых участников проекта со стороны предприятия (бухгалтер, финансист, руководитель по IT) очень хорошо пройти курс (~ 30 часов) по средству автоматизации (конфигурации, возможно по платформе 1с ) .

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

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

Для технических специалистов - с текущей ИС и организацией ИТ-инфраструктуры.

Затраты (в размере 30 часов на/чел.) обязательно «окупятся», а затем принесут еще экономию бюджету, так как качество работы участника проекта повысится ~ в 1.5 – 2 раза. А относительно трудозатрат на большом проекте – это большая экономия.
  • Функциональное моделирование и перенос данных;
Основа нормального технического задания – это тех. требования. В свою очередь требования нужно:
  • Выявить;
  • Оценить их значимость, возможности реализации, рассмотреть альтернативы и обходные варианты;
  • Принять требования, расставить приоритеты / либо отклонить и в тех. задание не включать.
В случае проектов 1С дополнительной сложностью является то, что требования должны быть «переложены» на возможности программы (обычно, в основе - типовая конфигурация 1С) и нужно «отталкиваться» от этого.
Т.е нужно смоделировать «что будет» (с использованием типового решения) и что нужно будет еще сделать/переделать и пр, что бы удовлетворить требования к системе со стороны заказчика.

Надо сразу понимать, что такое «моделирование» - сложная, творческая задача. Лучше всего ее решать совместными усилиями разных участников проектной команды. Для этого, участникам нужно предварительно подготовиться к работе (см. предыдущий пункт).

- Хлопотное, получается, дело.. Так ?

- Да.
- А можно ли не тратить время финансиста, бухгалтера, логиста и т.д. и не проводить функциональное моделирование ?

Можно, но в этом случае система будет проектироваться только исходя из представлений автора тех. задания. И вероятнее всего:
  • Либо будут упущения, искажения в понимании бизнес-процессов и то, «как их целесообразно автоматизировать»;
  • Либо будут упущения в части использования функционала программы (конфигурации 1С); будут предложены не рациональные, ошибочные пути решения.
Для компании выгодно, что бы в процессе функционального моделирования, на стороне заказчика выступал эксперт по 1С. Это обеспечит активное участие со стороны заказчика, и при этом повысит качество рассмотрения функциональных моделей, заставит рассмотреть и альтернативные варианты.

Одновременно с функциональным моделированием нужно задумываться над задачей переноса, ввода первоначальных данных. Эти задача (если еe не обдумать изначально) может принести большие проблемы проекту, его START UP. И как следствие – в дальнейшем возникнет ощутимое увеличение затрат.
Хорошей практикой является предварительный (так сказать «ознакомительный») перенос данных уже на этапе функционального моделирования.
Это будет очень полезно и для заполнения «модельной базы» данными, которые будут понятны для пользователя.
  • Этап №0 (фундамент проекта);
Подведем итоги... Для того, что бы:
  • повысить качество работы проектной команды;
  • суметь найти лучшие (компактные, рациональные) проектные решения;
  • хорошо подготовится к этапу переноса и START UP
- для этого нужно заложить крепкий фундамент проекта. А для этого и существует этап №0 «Подготовка к проекту».

Кроме функционального моделирования на этом этапе, обычно, выполняют предпроектное обследование бизнес-процессов и ИС заказчика.
Перечислю весь перечень задач, которые, обычно, выполняются на этом этапе:
  • (1) Поднятие компетенций участников проектной команды;
  • (2) Интервьюирование ключевых сотрудников со стороны заказчика по бизнес-процессам. Описание бизнес-процессов «Как есть». Фиксирование пожеланий «Как будет»;
  • (3) Ознакомительный перенос данных и подготовка информационных базы для функционального моделирования;
  • (4) Проведение функционального моделирования, фиксирование функциональных требований;
  • (5) Согласование основных настроек будущей ИС: учетная политика, состав основных справочных данных (подразделения, статьи затрат, номенклатурные группы, счета учета и т.д.).
Как показывает практика, хорошая подготовка к проекту – главный инструмент для снижения затрат бюджета и повышения качества проекта в целом.

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

- О чем еще пора задуматься? О производительности вашей материальной части (сервера и сеть). И особенно важно это для внедрения таких ресурсоемких программ, как УПП.
Практика показывается, что очень часто проект просто «встает» на этапе START UP, потому что о производительности оборудования попросту не побеспокоились.
- Работать невозможно, восьмерка «виснет». «Семерка» - работала быстрее!!
Что бы не «упереться» в производительность, необходимо рассчитать характеристики и подобрать оборудование (сервера), которые «потянут» работу вашей ИБ 1С.

И первое, что целесообразно сразу сделать – это оценить производительность имеющегося у вас оборудования.
Для этого, я рекомендую использовать нагрузочный тест Гилева. Это замечательный, признанный многими инструмент:



Если вы получите результат замера < 25, то это явное свидетельство низкой производительности.
Для УПП, например, приемлемый показатель минимум 35-40.
  • Расчет характеристик сервера и подбор оборудования
Основная характеристика, которую нужно учитывать при подборе оборудования – это планируемое количество одновременных пользовательских сеансов.
  • Расчет необходимой оперативной памяти на сервере рассчитывается «от количества пользователей», примерно так:

    Объем_ОЗУ = 240 мб * Колво_Пользователей + 2 Гб (для ОС) + 4 Гб (для SQL) + 4 Гб (для сервера 1С:Предприятия).

    Необходимый объем на 1-го пользователя может варироваться от 100 до 240 Мб для разных конфигураций.
  • Расчет необходимого количество ядер процессора так же рассчитывается относительно количество пользователей (максимум – 8 пользователей на 1 ядро).

    Т.е КолвоЯдерПроцессора = Колво_Пользователей/8 + 1 ядро (для сервера 1С Предприятия) + 1 ядро (для MS SQL);
К примеру, для сервера 1С со всем пакетом ПО, 50 терминальными пользователями в конфигурации «Управление Торговым Предприятием», и базой данных в 8GB оптимальной будет вычислительная мощность двух процессоров Intel Xeon E5-2650 (8 ядер, 16 потоков, 2.0 GHz). Оперативной памяти понадобится минимум 2 (ОС) + 4(SQL) + 4(1C-сервер) + 8 (160 «УТП» * 50 пользователей) = 18GB, а лучше 24-32GB(6-8 каналов DIMM по 4GB).

Для организации быстрой и надежной работы с данными, на сервере нужно организовать RAID-массив.
  • Что бы не наступить на известные грабли..
Приведу некоторые распространенные ошибки, из-за которых чаще всего страдает производительность:
  • Размещение на одном сервере терминала и сервера базы данных;
    • Нужно: терминал + сервер 1с на одном сервере. БД – на другом.

  • Cлабая дисковая подсистема
    • Нужно создать RAID (если он отсутствует), увеличить кол-во дисков, использовать высокоскоростные диски.

  • Низкая скорость передачи данных между MS SQL сервером, сервиром 1с предприятии, терминальным сервером.

    • Лучше всего, все разместить на одном физическом сервере (т.е использовать виртуализацию). В этом случает Ethernet-соединений между серверами не будет вообще.
    • Или использовать высокоскоростные Ethernet-соединения (10Gb Ethernet)

Подведем итоги: правильно подготовив мат. часть вы существенно сократите количество работ по «борьбе за производительность» на этапе внедрения. В противном случае, «тормоза» будут «убивать все плюсы» новой ИС, а борьба с ними (организованная «в пожарном порядке»!) заметно увеличит затраты проекта.

6. Лишнего не надо..
  • Реализм
Практика показывает, что до 20% функциональности разрабатываемой/дорабатываемой по тех. заданиям, при внедрении и дальнейшей работе – не используется.
Есть полезное правило: если некая программа есть, но она ни кем не используется, то значит - нет такой программы.

Что бы зря не работать (и не платить в «пустую») нужно руководствоваться реализмом, помнить об основных этапах становления ИС: документ – учет – планирование.
Т.е первое - обеспечиваем отражение в программе хоз. операций, бизнес-процессов и пр. документов. При этом, реализуем основные требования к учету. Это - главное.
Про задачи планирования помним и стремимся «приблизиться» к ним.

Таким образом, очень полезно провести независимый (от разработчиков ТЗ) аудит тех. заданий. Для того, что бы оценить «жизнеспособность» того, что предлагается реализовать, нужен опыт. Эту работу сможет провести эксперт по 1с (программист-аналитик).
  • Оптом не дешевле, лицензии, прочий софт
Как известно программы «1С» можно купить только через франчайзи.
И если, например, вы объявляете, что у вас сейчас 1 филиал, но скоро планируется открытие еще 3, то менеджер по продажам 1С обязательно посчитает кол-во программ (лицензий) для 4-х филиалов.
И это нормально. Работа у него такая. :-)

А ваша задачи – иная, оптимизировать затраты.

И нужно понимать, что в большинстве случаев, для лицензий 1С правило «оптом дешевле» не срабатывает. Т.е можно купить лицензий по минимуму, и при необходимости уже докупать пакетами по 5/10/20 лицензий и т.д.

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

Сложится может по разному..

Для целей подготовки, разработки, тестирования, переноса данных, обучения – достаточно минимального количества лицензий.
  • Торговое оборудование
Если в рамках проекта запланировано использование торгового оборудования, то также не стоит сразу его «массово» закупать.
Но тут ситуация несколько иная, чем с лицензиями. Оптом - будет дешевле, однако, советую - не торопится покупать сразу.

Дело вот в чем. Что бы ясно понять, что данная модель оборудования вам подходит, нужно поработать с ним.
И делать это (обязательно) нужно «в связке» с вашей ИС.
Тогда станут понятны нюансы.
Например, возможно, что оборудование-то неплохое, однако в связке с вашей программой работать с ним – неудобно и т.д. Т.е нюансов может быть много и задача подбора торгового оборудования – отдельная.

Кстати характерно, что цены на торговое оборудование в Китае (если закупать там), намного ниже, чем покупать в РФ.
Т.е можно самостоятельно подобрать оборудование и подключить его к вашей 1С. В этом вам так же сможет помочь эксперт по 1С.

7. Руководство проектом
  • интеллигентная твердость
Что бы настроить эффективную работу в проектной команде, что бы поддерживать качество и не растерять команду, руководителю проекта нужно проявлять такое качество, как интеллигентная твердость.

Т.е. просто проявлять твердость, настырность и все.. – это не правильно. Это - не бригадой строителей руководить.

С другой стороны, нужно проявлять требовательность, но делать это интеллигенто.
  • cамодисциплина
Часто так бывает, что руководить проектом берется некий «очень занятой человек».
Например, финансовый директор, заместитель управляющего компании и т.д.
Он очень загружен основной/прочей работой и времени на проект у него попросту нет.
Например, он в срок не успевает согласовать проектные документы, разобраться в проблеме, принять решение, изучить 1С и т.д.

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

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

Принятие сложных, спорных решений – одна из главных задач руководителя.

Очень распространена практика, когда руководитель «тянет» с принятием таких решений, то говорит «да», то – «нет», меняет свою позицию… А потом (в случае неудачи) «кивает» на подчиненного.
Это – плохая практика, которая расшатывает проектную команду.

Руководитель должен поступать так: сначала выслушать различные/спорные мнения, а затем, уже самостоятельно принять решение и отстаивать его выполнение.

8. Мотивация
  • Пряник и кнут
Рассмотрим (в двух словах) характерную ситуацию: руководство компании, главный бухгалтер и начальник IT задумали переход на новую 1С. У каждого – своя мотивация, свой интерес на этот счет.
Однако, втроем проект не реализуешь, и следовательно:
  • Для создания проекта нужно мотивация проектной команды;
  • Для внедрения – мотивация всех, в т.ч. и работников компании.
Предположим, что проектная команда собрана, в ней – профессионалы, работают с нормальными задачами за достойные деньги. В конце концов, проекты – это их работа.
А вот что касается работников компании на этапе внедрения, то зачем им нужен этот переход на новую 1С ?
У них и так «много своей работы», а тут нужно еще изучать новую программу. Да еще и участвовать в ее отладке?

Если не задумываться об этом и не заниматься мотивированием сотрудников, то сроки (а следовательно, и стоимость) внедрения сильно увеличиваются..

Для мотивирования существуют как финансовые, так и иные «рычаги». Рассмотрим эти возможности - начнем с финансовых. Т.е «кнут» и «пряник».
  • В качестве «пряника» хорошо срабатывает премия за успешное участие в проекте внедрения;
  • В качестве «кнута» - пониженные оценки эффективности работы сотрудника. И как следствие отсутствие (или понижение) материальных и карьерных благ.
  • Интерес
Теперь рассмотрим «нематериальные» рычаги стимулирования. Они есть и ими нужно умело пользоваться. Хотя, конечно, все зависит от индивидуальности человека и не для всех это сработает.

И тем не менее… Освоение новой программы может восприниматься не только как обременительное, но и как интересное занятие:
  • Становиться меньше рутинной, скучной работы. Появляется что-то «свежее», в более «продвинутой» программе;
  • Знание «новой» программы пригодится не только на данном рабочем месте, но и будет плюсом при переходе на другую работу.
  • Энтузиазм
Ощущение того, что у тебя получается (начало получаться), что ты осваиваешь что-то новое, что ты начинаешь в этом разбираться - все это вызывает энтузиазм.
Очень эффективно, например, провести предпроектное обучение по 1С ключевых сотрудникам заказчика.
В случае успешного ознакомление с программой, понимания ее сильных сторон, возможностей, у заказчика возникает уверенность и энтузиазм в работе над проектом.

9. Start UP

Самый напряженный и непростой этап на проекте – это START UP.
Что бы пояснить эту мысль подойдет, пожалуй, такая цитата:

Всякая революция лишь тогда чего-нибудь стоит, если она умеет защищаться (В.И. Ленин)
Далее приведу ряд советов, что бы пройти этот этап с наименьшими потерями и добиться результатов.
  • Перенос данных
Перенос данных, пожалуй, можно сравнить с квартирным переездом…
Нужно продумывать детали, рассчитывать… Однако, «гладко» все никогда не пойдет. И часть вещей придется оставить за пределами новой квартиры.

Практика показывает, что срабатывают следующие правила:

1. Перенос данных должен быть простым. Закладывать сложные схемы, тратить много времени на их реализацию – не эффективно. В ограниченных временных условиях (во время переезда жить на улице не хочется J ) сложные схемы не сработают.

2. Придется проверять и «крыжить» данные (кто не знает, что такое «крыжить» – выясните у бухгалтера). Нужно заранее сформировать спецбригаду под эту работу и оснастить ее необходимым инструментарием (универсальные обработки 1С и т.д.)

3. Назначить deadline и … глубоко вдохнуть.
  • Обучение сотрудников, консультирование, разбор полетов
Что бы сотрудники смогли более-менее разумно начать работать в программе, их надо этой новой программе обучить. Приведу несколько советов, как это делается:
  • Обучение должно происходить непосредственно (за день-два) перед намеченным сроком начала работы в программе. Ошибочно проводить обучение заранее – все забудут, чему их учили. Т.е – попусту потраченное время.
  • Нужно проводить обучение в офисе заказчика, группируя сотрудников по отделам.

Например, собирают менеджеров клиентского отдела перед большим экраном.. И девушка (консультант по 1С) показывает им на экране «как оформлять заказы клиентов», отвечает на вопросы приятным голосом.

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

По этому, результатами «первичного» обучения должны быть:
  • Общее понимание того, что нужно предстоит делать в программе;
  • Получение пользовательских инструкций.
Т.е консультант обязательно! должен подготовить пользовательские инструкции со скрин-шотами («что каждый отдел должен будет делать в программе»).

Очень хорошо, если какие-то инструкции есть в вашей конфигурации в виде хелпов к объектам. Пускай - даже кратенько.

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

START UP – напряженный момент, когда одного консультанта на всех не хватает. На этот этап стоит привлечь дополнительные ресурсы.

И вот, программа заработала и … посыпались ошибки. :-(

А куда же без них
?

Здесь стоит привести еще одну цитату:

Правопорядок в стране определяется не наличием воров, а умением властей их обезвреживать! (Глеб Жеглов).
Т.е основная задача – оперативно реагировать, выявлять причины ошибок и исправлять их. Приведу пару советов по организации данного процесса. Основной момент – нужно централизовать прием и диагностику ошибок.
  • Нужно организовать линию тех. поддержки. Все ошибки должны отправляться на тех. поддержку. Там – регистрироваться, расставляться приоритеты (по важности) и сроки исправления.
  • Аналитики, проектировщики, ведущие программисты должны получать информацию об ошибках, определять способы их исправления и ответственных за это.
  • Нужно стараться обеспечивать исправление ошибок таким образом, что «лишний раз не дергать» всех пользователей и «не выгонять» их из базы.

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

Еще начиная с этапа №0 нужно стремиться минимизировать такие ошибки, но все равно они будут.
И если такая ошибка выявлена, то (по существу) речь будет идти не об ее исправлении, а о корректировке тех. задания, переделке того, что сделано, новых задачах, подпроектах и т.п.

Этой ситуацией, всегда недовольны обе стороны – и заказчик (он недоволен, почему не сделали.. :-( ) и подрядчик (почему так объяснили, почему подписали ТЗ..).
И далее, всегда возникает спорный вопрос: кто будет нести издержки по исправлению таких ошибок:
  • Заказчик будет настаивать, что это «косяк» подрядчика и исправление - за его счет;
  • Подрядчик будет настаивать, что это «доп. работа» и оплатить ее должен заказчик.
Для урегулирования острых, не простых ситуаций хорошо подходит вариант «50 % на 50%». Т.е «косяк» признается двухсторонним и издержки на его исправление стороны делят пополам.

10. Этапы становление ИС
  • Документ – Учет – Планирование
Допустим, что проект таки прошел точку START UP. Пользователи вводят в базу документы, выдают документы контрагентам, оформляют другие операции.

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

И если вдруг выясняется, что возникают «дырки», какие-то механизмы «работает криво» или вообще «отвалились», то нужно срочно исправлять ситуацию.
Надо понимать, что с каждым днем восстановить учет, исправить ситуацию будет все сложнее и сложнее.

Все основные учетные механизмы:
  • ТМЦ на складах;
  • Взаиморасчеты с контрагентами;
  • Выручка;
  • Себестоимость;
  • Доходы и расходы;
следует поддерживать в актуальном состоянии сразу.

Двигаемся дальше и, предположим, что с учетом вы справились. Что дальше ?
Далее, нужно налаживать планирование.
Обычно, это задачи:
  • Оперативного планирования денежных средств;
  • Планирования продаж, управление заказами клиентов;
  • Планирования закупок, обеспечения. Управления заказами поставщиков;
Ну а после этого, уже можно переходить к задачам долгосрочного планирования (бюджетирования).
  • Ограничения доступа, персонализация интрефейсов, АРМ
Параллельно с налаживанием учета, чаще всего приходятся решать задачи «точечного» ограничения доступа пользователей и настройку их интерфейсов. Обычно, руководство подразделений активно ставит такие задачи по ходу первичного внедрения.
Прописывая «точечные» ограничения и настраивая интерфейсы (кто из пользователей может увидеть/изменить такой-то реквизит, как определить «чужие» данные, кто может чужие данные изменить и т.д.) де-факто налаживаются, утверждаются регламенты работы подразделений с документами и прочими данными.

Ну и наконец, сами пользователи начинают процесс «юзабилити». Т.е инициируют задачи по созданию для них АРМ (автоматизированных рабочих мест), т.е. что бы было все «под рукой», ничего лишнего, и что бы «не лазить в отчеты».
  • От внедрения к сопровождению
Ну что, пора завершать повествование. :- ) Представим, что наше внедрение подходит к концу и с задачами мы справились.
Что дальше ?

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

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

.$.
Открыть

    © 2011 Горский Михаил.