Анализ вариантов организации работ на проектах 1С

12.11.21

Анализ и управление - Управление проектом

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

Выбор правильной технологии управления проектом внедрения — первый шаг к успеху автоматизации работы предприятия.

Практика внедрения программных продуктов для бизнеса, 1С ERP в том числе, использует несколько методик:

  • Классическая, каскадная или «водопадная» модель;
  • V-модель;
  • Инкрементная модель (модель снижения риска) или «мульти-водопад»;
  • Итерационная, спиральная модель (некоторые аналитики считают, что это 2 разные модели);
  • Agile / Scrum;

Существуют и другие варианты моделей внедрения, такие как Сашими, рациональный унифицированный процесс (RUP), методология «чистой комнаты» (Cleanroom) и др. Но все эти модели могут быть отнесены к разновидности классического варианта, поскольку они являются последовательными, с четкой границей между этапами. К Agile относят методики FDD, Kanban, экстремальное программирование (XP), Lean и т.д.

 

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

  • от направленности проекта (переход с 1С УПП на 1С ERP, внедрение 1С ERP «с нуля», развитие системы, новая попытка внедрения и т.п.);
  • от этапа жизненного цикла компании заказчика,
  • от организационной структуры,
  • от зрелости системы управления предприятия,
  • от порядка финансирования,
  • от особенностей бизнеса,
  • от личных субъективных предпочтений руководителей,
  • от опыта и наработок поставщика услуги.

 

Сравнительный анализ различных моделей управления проектом – полезная информация для принятия решения

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

 

 

Классическая, каскадная или «водопадная» модель

Agile / Scrum

 

V-модель

Инкрементная модель (модель снижения риска) или «мульти-водопад»

Итерационная, спиральная модель (некоторые аналитики считают, что это 2 разные модели)

Описание

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

Работа разделена на отдельные шаги – Спринты («Sprint»). Регулярные собрания подводят итоги прошедшего шага и формируют перечень задач нового шага.

После каждого шага заказчик может использовать результат и оценить, его.

Вариант классической модели.

Стадия тестирования (функционального, нагрузочного, интеграционного) проводится параллельно со стадией настройки и доработки.

Поэтапное внедрение системы.

Каждый модуль при внедрении проходит через этапы классической модели.

На старте внедрения необязательна полная спецификация требований. Внедрение начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется «по спирали».

Условия применения модели

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

Подходит для внедрений, адаптируемых к сложным меняющимся условиям и пожеланиям пользователей.

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

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

Когда основные требования к системе четко определены и понятны. Но в то же время требования к дополнительным модулям не сформированы окончательно и могут дорабатываться с течением времени.

Проект большой или очень большой.

Требования к конечному результату заранее чётко не определены.

Хорошо подходит для автоматизации сложных, но критически важных бизнес-процессов.

Риски и критические условия реализации проекта

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

Есть риск, что конечный результат может иметь недочёты, на устранение которых понадобятся дополнительные ресурсы

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

Исполнитель полностью несет ответственность за срыв сроков и незапланированное увеличение бюджета.

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

Представители заказчика по внедряемому модулю принимают активное участие во внедрении на протяжении всего проекта.

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

Частые запросы на оценку работы системы могут вызвать раздражение пользователей.

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

 

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

Предполагает 4 этапа для каждого витка:

1.    исследование и планирование;

2.    анализ рисков;

3.    разработка и внедрение;

4.    оценка результата и при удовлетворительном качестве переход к новому витку или новому модулю.

Результат может быть не неидеален, главное, чтобы система работала.

Уровень сложности управления проектом

Простая, понятная логика и структура проекта, как для опытных специалистов, так и для новичков.

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

Соответствует уровню классической водопадной модели управления проектом.

Не нужно использовать много ресурсов на начальном этапе.

Соответствует уровню классической водопадной модели управления проектом.

Скорость внедрения

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

Позволяет быстро получать локальный результат после коротких шагов.

Высокая за счет распараллеливания этапов внедрения.

Рабочая эксплуатация возможна только после завершения последнего этапа.

Высокая за счет последовательного ввода подсистем.

Рабочая эксплуатация начинается с ввода первой подсистемы.

Высокая за счет последовательного ввода подсистем.

Рабочая эксплуатация начинается с ввода базовой подсистемы.

Сроки и стоимость внедрения

Стоимость фиксированная.

Сроки заранее определены.

Сложно заранее оценить стоимость.

Сроки жёстко не определены.

Стоимость фиксированная.

Сроки заранее определены.

Стоимость фиксированная.

Сроки заранее определены.

Отсутствие фиксированного бюджета и сроков.

Гибкость, возможность оперативных изменений

Нет возможности сделать шаг назад, список требований нельзя скорректировать в любой момент.

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

Возможность внесения изменений на каждом шаге проекта.

Примерно соответствует гибкости классической модели управления проектом.

Позволяет внести изменения еще на стадии разработки за счет параллельного тестирования.

Ошибка обходится дешевле за счет более короткого шага для получения результата.

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

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

Условия оперативных изменений

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

Не нужно нанимать команду тестировщиков, можно опираться на подробную техническую документацию.

Эффективное взаимодействие в команде важнее процессов и технологий.

Необходимо достаточное количество инженеров тестировщиков.

 

 

 

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

 

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

Уверен, это вполне достижимо: в рамках одного проекта можно оптимально совместить Agile и Waterfall. Более того, это даже рекомендуется в ряде случаев. Такой подход реализуется на основе гибридных моделей (V, инкрементной, итерационной, спиральной). При разработке плана проекта верхнего уровня мы предлагаем опираться на долгосрочные цели, а конкретные этапы (учитывая специфику работ на них) «нарезать» на задачи, решаемые гибкими методами. Суть такого подхода - выбрать наиболее подходящую тактику для каждой фазы проекта.

 

Хотелось бы кратко остановиться на одном крайне непродуктивном подходе.

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

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

 

Наши рекомендации заказчику до начала проекта для повышения качества результата.

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

1) максимально точно определить цели проекта;

2) детализировать (насколько возможно) границы и требования к системе;

3) критично взвесить свои возможности и ресурсы - определиться, что можно сделать самим, что заказать на стороне, и что лучше сделать совместными усилиями;

4) запросить предварительные оценки и технологии реализации проекта от потенциальных подрядчиков;

5) привлечь экспертов для анализа представленных вариантов на наличие рисков и их исполнимость;

6) обсудить с потенциальными подрядчиками возможность корректировки предложения;

7) выявить профессиональный уровень подрядчика, его умение и желание работать;

8) доработать совместно с подрядчиком план проекта до рабочей версии;

9) провести переговоры для заключения контракта;

управление проектами водопадная модель V-модель инкрементная итерационная спиральная Agile / Scrum

См. также

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Управление проектом Внедрение ИТ-системы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    12361    ASchekachev    36    

48

Организация работы внутренней команды 1С с помощью Канбан

Управление проектом Управление командой Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    4940    stnslv    5    

23

Анализ & Управление в ИТ-проектах, 30 мая - 1 июня 2024 г., Санкт-Петербург

Анализ и управление Управление проектом Анализ и проектирование ИТ-систем Мероприятия Россия Платные (руб)

Практическая конференция для аналитиков и руководителей проектов 1С. 30 мая - 1 июня 2024 г. Санкт-Петербург, отель Park Inn by Radisson Pribaltiyskaya, ул. Кораблестроителей 14

30000 руб.

27.05.2023    15852    1    0    

5

Технология проекта внедрения 1С:ERP – как управлять большим проектом

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

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

10.02.2023    3521    andironenko    2    

28

На что похож ваш продукт: на Аквариум или на Муравейник? 

Управление проектом Бесплатно (free)

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

27.12.2022    2241    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    2915    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Внедрение ИТ-системы Управление проектом Управление командой Управление ИТ-подразделением Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

09.09.2022    8698    biimmap    79    

65

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    11478    Evil Beaver    17    

108
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. DBTransformer 12.11.21 15:09 Сейчас в теме
Вопрос 1. Получается, чем крупнее бизнес и сложнее проект, тем выше потребность Заказчика в гарантиях получения требуемого результата. И ищет он эти гарантии не в компетенциях Исполнителя, а фактически требует от Исполнителя брать на себя невыполнимые обязательства. При такой постановке квалифицированный и ответственный Исполнитель никогда не получит заказ, а Исполнитель, готовый пообещать всё, что попросят, способен добиться достижения целей только случайно. В итоге Заказчик вместо гарантированного срока и стоимости проекта получает результат, обратный требуемому. Такая ситуация может быт связана с распределением ролей участников проекта в команде Заказчика?
4. Soliton 298 13.11.21 17:12 Сейчас в теме
(1)

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

Исполнитель, готовый "пообещать всё, что попросят", никогда не добивается достижения целей...

=== Такая ситуация может быт связана с распределением ролей участников проекта в команде Заказчика?

Не совсем понял данный вопрос. Пожалуйста, поясните чуть шире?
DBTransformer; +1 Ответить
6. DBTransformer 16.11.21 13:11 Сейчас в теме
(4) Различие ролей со стороны Заказчика состоит в том, что в результате, выраженном в росте эффективности и устойчивости бизнеса, заинтересованы владельцы и высший менеджмент. А непосредственным руководством сложным проектом занимается руководитель службы ИТ, заинтересованный в минимизации личных рисков.
5. Petr54-ru 90 16.11.21 12:47 Сейчас в теме
(1) Оба ваших вопроса - и вопрос 1 и вопрос 2. Решаются путем вытягивания Заказчика на проект по предпроектным исследованиям. За деньги естественно.

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

С этим документом Заказчик может пойти к конкурента и попросить упасть по цене и срокам. Вам без разницы, вы за это исследование деньги уже получили.
7. DBTransformer 16.11.21 13:18 Сейчас в теме
(5) Не так всё просто. заказчик пойдёт к конкурентам, те упадут в ценах. Если цена была обоснованной, конкурент не оправдает ожидания заказчика, система внедрится непонятно как. В итоге клиент вернётся к ответственному исполнителю, подготовившему первоначальное ТЗ. Исправлять то, что испортили другие, сложнее, чем делать заново. Поэтому стоимость второй попытки внедрения окажется дороже первоначального ТЗ. В итоге заказчик инвестирует в развитие информационной системы в два с лишним раза больше, чем в соответствии с первым ТЗ, времени - раза в три - пять больше. И упустит ряд возможностей развития своего бизнеса. Но если заказчику очень хочется приключений, никто в этом ему помешать не сможет.
8. Petr54-ru 90 16.11.21 13:56 Сейчас в теме
(7) Фундаментальный принцип работы в ИТ - с чудаками на букву Эм не работаем. Если они ушли к конкурентам, то флаг им в руки и барабан на шею. Не надо работать с нелояльными клиентами, пусть с ними работают конкуренты. И то что потом на стороне заказчика случится, нам вообще не интересно. Если ничего у него не выйдет, и он вернется взад, то надо цену поднимать, как минимум процентов на 20%, - наценка за нелояльность и потому что у конкурентов не вышло.

В реальной жизни, у ИТ-директора со стороны заказчика свои исполнители имеются, и не одни, которые костьми лягут, чтобы его не подставить и еще откатят ему, были бы заказы
9. DBTransformer 16.11.21 14:49 Сейчас в теме
(8) При таком подходе так и будете сидеть на предпроектных исследованиях и делать ТЗ для других внедренцев. А потом к Вам и за предпроектными исследованиями обращаться перестанут, поскольку внедрений у Вас не будет.
11. Михаил_65 16.11.21 15:05 Сейчас в теме
(9)
внедрений у Вас не будет.

А что хуже? Неудачное, провальное внедрение? Или отсутствие "халтурных" проектов, а внедрения пусть редкие, но успешные?
12. DBTransformer 16.11.21 15:11 Сейчас в теме
(11) Странная альтернатива. Идея всегда работать качественно мне больше нравится.
13. Petr54-ru 90 17.11.21 07:50 Сейчас в теме
(9) Этот наш бизнес очень похож на преферанс. Провальный проект - это считай паровоз на мизере. Чудаки на букву Эм, в лице заказчика вам залет обязательно обеспечат.

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

С другой стороны, полно технологий обеспечения лояльности заказчика без того, чтобы падать по цене. Как говорили во времена оные - "Мы сделаем все что угодно, если найдем кому поручить". Если у вас есть люди, способные обеспечивать лояльность заказчика на протяжение выполнения всего проекта, то все у вас будет хорошо, и никакие конкуренты вам не страшны.
10. Михаил_65 16.11.21 14:54 Сейчас в теме
(8)
ИТ-директора со стороны заказчика свои исполнители имеются, и не одни, которые костьми лягут, чтобы его не подставить и еще откатят ему, были бы заказы


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

Если внедрение ERP проходит через собственные отделы информационных технологий, то руководителем компании обычно движет «железная» уверенность в том, что собственные специалисты в любом случае лучше «варягов» сумеют разобраться в специфике работы предприятия и вникнуть в требования пользователей. К тому же добавляется вполне понятное желание сэкономить.
Но при этом:
1. Управление проектом делегировано директору по IT. Руководство изначально считает проект внедрения задачей для программистов и не думает активно участвовать в нём.
2. Проблемы внедрения решаются расширением штата программистов.
3. Функционал и возможности установленной ERP мало интересуют руководителей и топ- менеджеров.
4. ITшники больше внимания уделяют качеству кода и скорости работы системы, чем объективным требованиям бизнеса и системы управления.
В такой компании ERP полноценно внедрено не будет.

Шанс появляется, если директор по IT не замыкается в задачах цифровизации и понимает, что внедрение ERP – это не самоцель, а внедрённая система должна служить интересам предприятия, бизнесу.
Soliton; DBTransformer; +2 Ответить
14. Petr54-ru 90 17.11.21 07:57 Сейчас в теме
(10)
Шанс появляется, если директор по IT не замыкается в задачах цифровизации и понимает, что внедрение ERP – это не самоцель, а внедрённая система должна служить интересам предприятия, бизнесу.


Еще какая самоцель, например если ИТ дректору нужно поиметь в резюме строки типа - "успешное руководство внедрением ERP", ну или получить * процентов 10 от стоимости лицензий.

Еще можно расширив штат департамента повысить свою капитализацию на рынке.
2. DBTransformer 12.11.21 15:13 Сейчас в теме
Вопрос 2. В автоматизации и повышении эффективности управления заинтересованы владельцы и высший менеджмент предприятия Заказчика, а ответственность за отбор Исполнителя и реализацию проекта несёт руководитель департамента информационных технологий. Стоимость проекта высока. Влияние результатов проекта на показатели бизнеса может превосходить стоимость проекта в десятки и сотни раз. И в такой ситуации руководитель подразделения информационных технологий оказывается заинтересован в минимизации собственных рисков, что и приводит его к требованию от Исполнителя сроков и стоимости работ, точно предсказать которые при качественном внедрении часто невозможно. Как правильно Заказчику распределить роли участников проекта со своей стороны, чтобы не попасть в собственную организационную ловушку? Как Исполнителю правильно строить работу с учётом распределение ролей в команде Заказчика?
3. Soliton 298 13.11.21 17:09 Сейчас в теме
(2)

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

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

=== Как Исполнителю правильно строить работу с учётом распределение ролей в команде Заказчика?

Для этого существует технология "анализа карты сил на проекте".
DBTransformer; +1 Ответить
Оставьте свое сообщение