Применение методологии внедрения проектов Майкрософт на проектах внедрения 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С.

См. также

Фаза пресейла: насколько глубоко нужно погружаться в бизнес-домен?

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

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

25.03.2024    231    0    alenkaiva    0    

2

Как реорганизовать работу проектного департамента, чтобы быть №1

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

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

14.02.2024    558    0    user1270271    2    

7

Управление ожиданиями на проекте

Работа с заинтересованными сторонами Бесплатно (free)

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

08.02.2024    453    0    izybaevda    0    

5

Как внедрить 1С:ERP за 2 года и не сойти с ума

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

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

30.01.2024    6707    0    user1578851    16    

16

Свободное программное обеспечение в крупной компании – миф или реальность? Как мы переводили 2500 пользователей на Linux

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

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

29.01.2024    2418    0    user1063453    2    

5

Зачем нужны аналитики на проектах автоматизации

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

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

18.01.2024    1592    0    user1754524    19    

12

Радио "Аналитик", 7 выпуск 2 сезона. Про работу аналитика с бизнесом и повышение бизнес-компетенций с Константином Семёновым

Анализ предметной области Работа с заинтересованными сторонами Анализ потребностей и поиск решений

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

28.11.2023    414    0    Radio_Analyst    0    

2
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. awk 741 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 741 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 156 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 21 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С звучал примерно так "Марь Иванна, мы вам компьютеры купили? Купили. Программиста наняли? Наняли. Вот вы ему и расскажите как настроить программу вашу, он вам всё сделает." А программист в учёте - ни в зуб ногой. Так же как и Марь Иванна в компьютерах. Вот и лепили они что могли.
Оставьте свое сообщение