Применение методологии внедрения проектов Майкрософт на проектах внедрения 1С

08.10.20

Бизнес-анализ

Практика применения фирменной методологии внедрения SureStep от Майкрософт на проектах внедрения продуктов 1С.

Применение методологии внедрения проектов Майкрософт на проектах внедрения 1С.

Введение и предпосылки.

В свое время мне довелось поработать консультантом по внедрению ERP-системы MS Dynamics AX на одном из партнеров Майкрософт. Опыт был достаточно интересный если учесть, что до этого я 15 лет занимался 1С во всех возможных ролях начиная от программиста, заканчивая руководителем отдела внедрения.

Нужно сказать, что для внедрения ERP-систем Майкрософт использует свою собственную методологию SureStep по которой в обязательном порядке сертифицируются все сотрудники всех партнеров. Методология опирается на идеологию управления проектами PMI, по которой я в своё время сертифицировался. Поэтому SureStep мне что называется «зашла на ура».

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

Ведь действительно язык программирования – русскоязычный Basic, классов не так много, и они не сложные. Мне приходилось встречать и бухгалтеров, освоивших простейшее программирование и системных администраторов наловчившихся «поправлять формочки».

С одной стороны, это играет на руку популяризации продуктов 1С. С другой порождает «кривые» внедрения со всеми вытекающими.

Давайте попробуем разобраться почему же у международных ERP-систем сложилась репутация «дорого и качественно», а у 1С наоборот. На мой взгляд корень проблемы даже не в стремлении заказчика сделать по-быстрому и подешевле, оно естественно. Корень проблемы в непонимании и, следовательно, неумении специалиста внедряющего систему объяснить заказчику почему так делать нельзя и как нужно.

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

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

Как сказал один умный человек: если ты сделаешь что-то быстро и неправильно, то все запомнят, что ты сделал неправильно, но никто не вспомнит что ты сделал быстро.

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

 

Основная часть

 

 

Чему же учит SureStep если объяснять «на пальцах»? Прежде всего конечно же документирование и версионность всех шагов процесса внедрения и распределение ролей участников, как со стороны подрядчика, так и со стороны заказчика.

Документ «Функциональные требования».

Самым важным ключевым документом я бы назвал функциональные требования или функциональный дизайн (в оригинале FDD – Functional Design Document). По сути, это описание поведения системы после доработок, написанное на языке пользователя. В документе не должно быть специальных терминов понятных только специалисту (например «Регистр сведений») и в него обязательно должны быть включены сквозные положительные и отрицательные сценарии тестирования с конкретными числовыми примерами.

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

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

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

Документ «Технические требования».

После утверждения функциональных требований в отдельных случаях разрабатывается документ технических требований или технического дизайна, в оригинале TDD – technical design document. Это по сути классическое техническое задание или спецификация, в котором для программиста и на языке программиста описаны все тонкости реализации. Именно при разработке этого документа разрабатываются, продумываются и анализируются всех архитектурные решения – какой регистр создать, с какими измерениями и ресурсами, структуры документов, справочников и т.п.

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

Роли в проекте.

Руководитель проекта.

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

Аналитик-консультант.

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

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

Функциональный архитектор.

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

Технический архитектор.

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

Программист.

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

Тестировщик.

Этой ролью чаще всего пренебрегают в проектах внедрения 1С. А зря. При внедрении АХ доработка считается принятой заказчиком только если есть документальное подтверждение успешного прохождения ВСЕХ шагов ВСЕХ тестовых сценариев. Да, это дорого и долго, но качество возрастает на порядок.

Общие моменты.

Само собой, на проекте должна быть удобная система bug-tracker, в которой создаются ticket-ы по которым можно отследить всю историю каждого вопроса – включая все версии всех документов, плановые и фактически трудозатраты и всю переписку по данному вопросу.

Почему важная версионность всех документов. Простой пример: по одному из требований было 10 версий функциональных требований. Общая трудоемкость доработок составила условно 20 часов, но если любому специалисту показать только последнюю версию требований и попросить оценить доработки, то получится 2 часа. На вопросы «почему так дорого? На что ушли остальные 18 часов» молча высылаю всю историю версий требований и вопросы тут же отпадают потому заказчик зачастую сам не знает, чего хочет, и уговоры консультанта-аналитики ограничится на первом этапе типовым функционалом должного эффекта не имеют. И начинается: «а давайте попробуем вот так! Ой, нет – не то. Давайте обратно как было!». А это всё часы работы специалистов, которые стоят денег.

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

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

См. также

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Большинство бухгалтеров привыкли вести учет в конфигурации 1С:Бухгалтерия. Но что бывает, если такого бухгалтера перевести с 1С:Бухгалтерии на ERP? Об основных ошибках бухгалтера после перехода и роли аналитика в том, чтобы помочь бухгалтеру преодолеть трудности и изменить привычные паттерны, пойдет речь в статье.

15.05.2024    4238    0    TanyaRi    69    

26

Внедрение изменений Бесплатно (free)

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

15.05.2024    5547    0    cesar    15    

49

Проектирование Анализ предметной области Бесплатно (free)

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

13.05.2024    429    0    Radio_Analyst    0    

3

Анализ предметной области Бесплатно (free)

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

03.05.2024    860    0    Polav62    9    

4

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Статья об основных зонах внимания и часто допускаемых ошибках при внедрении современных ERP-систем – «1С:ERP Управление предприятием» и «1С:ERP.Управление холдингом».

27.04.2024    2139    0    user893825    0    

17

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    568    0    Radio_Analyst    0    

5

Анализ потребностей и поиск решений Бесплатно (free)

Расскажем о Customer Development (CustDev) в заказной разработке, методиках исследования и проверке гипотез при создании MVP. Восстановим справедливость в отношении CustDev: рассмотрим, что это такое, и поделимся практикой применения.

18.04.2024    691    0    tachenkov    0    

4

Анализ предметной области Бесплатно (free)

В этой части статьи предложен вариант профессиональной мировоззренческой модели на основе пары взаимосвязанных реальностей – хозяйственной реальности и бухгалтерской (виртуальной) реальности.

09.04.2024    1124    0    Polav62    0    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. awk 743 08.10.20 16:14 Сейчас в теме
Тестировщик.

Этой ролью чаще всего пренебрегают в проектах внедрения 1С. А зря. При внедрении АХ доработка считается принятой заказчиком только если есть документальное подтверждение успешного прохождения ВСЕХ шагов ВСЕХ тестовых сценариев. Да, это дорого и долго, но качество возрастает на порядок.


Пять лет ною о создании отдела тестирования - все бестолку. А ведь в его отсутствии тестирование все равно будет, только делать его вудут в лучшем случае аналитик-консультант, в худшем - пользователь.
Fox-trot; +1 Ответить
2. impextr 88 08.10.20 16:50 Сейчас в теме
(1) да, практика такова что свои штатные специлисты годами ноют, а внешние подрядчики приходят, требуют и им сразу дают. Ну или подрядчики сразу уходят))
Понимаю. Тестирование на уровне "я сказал тёте Клаве чтобы проверила все доработки" достало.
3. Ta_Da 08.10.20 22:36 Сейчас в теме
(2) "Нет пророка в своем отечестве"
8. stepan_s 12.10.20 07:41 Сейчас в теме
(1) а зачем ноете... Роль тестировщик сейчас кто то выполняет. Чтоб показать что это труд лучше отдать специализированному человеку и высвободить того, кто не должен - соберите нагрузку и поддержку тех, кто не должен это делать.
Деньги универсальное мерилово - если показать что аналитик стоимостью часа 100 рублей выполняет работу тестировщика за 50 руб.
Мы сразу увидим сколько теряем. И ныть не надо :)
Но если выгоды нет, сами успокоитесь что организовано пока правильно :)
9. awk 743 12.10.20 08:35 Сейчас в теме
(8)Уже показал... Только ответ всегда один: "Конечно, ты прав. Вот сейчас наймем людей и...". И так 5 лет. :)
4. ilya2184 62 09.10.20 09:14 Сейчас в теме
Хорошая заметка.
Я бы писал SureStep вместо ShureStep
5. impextr 88 09.10.20 09:40 Сейчас в теме
(4) Спасибо, исправил.
Почему-то всегда был уверен что название от английских слов shure step - уверенный шаг
6. Fox-trot 160 09.10.20 09:53 Сейчас в теме
(5)
исправил
не везде )) глаз режет, исправь плиз
7. BigClock 09.10.20 14:49 Сейчас в теме
Очень мелкие картинки сразу после заголовка "Основная часть".
Там случайно не одна и та же картинка дважды приведена?

Лучше дать ссылку на сайт Microsoft:
http://download.microsoft.com/documents/rus/dynamics/pdffiles/dynamics_surestep.pdf
10. impextr 88 12.10.20 09:12 Сейчас в теме
(7) вот любят тут картинки)
Вам шашечки или ехать? (с)
11. ICeZm 23 12.10.20 14:15 Сейчас в теме
Интересная статья, спасибо.
12. stclean 18.01.21 08:51 Сейчас в теме
Начиная с 2005 года только так и внедряли 1С.
А разве есть другие подходы?
Наверно мне повезло, то попал в нужную команду (компанию) еще тогда, т.к. в этой компании уже были внедрены стандарты СМК по проектному управлению и внедрению ПП на платформе 1С.
13. impextr 88 18.01.21 18:39 Сейчас в теме
(12) конечно есть другие подходы
Самый "любимый", особенно популярный на заре распространения 1С звучал примерно так "Марь Иванна, мы вам компьютеры купили? Купили. Программиста наняли? Наняли. Вот вы ему и расскажите как настроить программу вашу, он вам всё сделает." А программист в учёте - ни в зуб ногой. Так же как и Марь Иванна в компьютерах. Вот и лепили они что могли.
Оставьте свое сообщение