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

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

04.12.2024    762    0    bolikov    13    

5

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

В данной статье рассматриваются задачи, которые необходимо решить при поэтапном внедрении 1С: ERP на крупном предприятии. Рассмотрен вариант перехода с успешно функционирующей 1С: УПП. Предлагается обсудить правильность принятых решений.

29.10.2024    709    0    VicCva    1    

4

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

Мы провели опрос заказчиков с целью определить степень удовлетворенности внедрением 1С: ERP. Опрос проводился по случайной выборке из списка внедренных решений на сайте 1С. Обработали 121 интервью от 97 компаний. Из выборки мы исключали "показательные внедрения" и крупнейшие холдинги, старались получить срез по "средним" массовым заказчикам. Статья будет интересна сотрудникам отделов продаж и отделов качества фирм, внедряющих 1С, потенциальным заказчикам и всем, кто интересуется статистикой внедрения 1С: ERP. Текст статьи довольно большой, в некоторой степени наукообразный.

16.10.2024    1500    0    Soliton    8    

8

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

Тенденции последнего времени заставляют пересматривать привычные инструменты, менять подходы, подстраиваться под рынок труда. Расскажем об импортозамещении инструментария внедренцев, отличиях Agile от почасовки и рисках дефицита специалистов 1С.

13.09.2024    2575    0    glebushka    3    

8

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

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

02.09.2024    1333    0    user1669221    2    

7

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

Когда при внедрении систем 1С всплывает слово «ГОСТ» – практически всегда речь идёт о документе «Техническое задание». И у большинства внедренцев падает настроение, как только им говорят, что надо «написать ТЗ по ГОСТу». Но опытные кулинары знают, как готовить это блюдо так, чтобы оно оставило после себя приятное послевкусие, а не горькое разочарование. О собственных рецептах приготовления документации по ГОСТу пойдет речь в статье.

21.08.2024    2870    56    Laya    3    

22

Анализ предметной области Анализ потребностей и поиск решений Бизнес-аналитик Руководитель проекта Управленческий учет Бесплатно (free)

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

19.08.2024    1669    0    SergeyN    0    

6

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

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

19.08.2024    9723    0    vladshelshel    7    

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