Предыдущие материалы на эту тему можно посмотреть по ссылкам:
- Мотивация персонала //infostart.ru/public/605716/
- Как всё начиналось //infostart.ru/public/608547/
- Проектная команда //infostart.ru/public/612086/
Как было рассказано в прошлой статье, внедрение «1С:ERP» — это, как правило, долгосрочный и дорогостоящий проект.
Само определение проекта предполагает, что производится что-то уникальное и неповторимое. Можно ли как-то формализовать этот уникальный процесс и добиться предсказуемых результатов в определенные сроки и с определенным бюджетом?
Можно и нужно, хотя и достаточно сложно. Помочь здесь Вам может проектная технология. Расскажем о ней на примере её использования во Внедренческом Центре «Раздолье».
Пресейл и экспресс-обследование
По настоящему проект начинается задолго до фактического начала работ – в тот момент, когда руководитель будущего проекта готовит для потенциального заказчика коммерческое предложение. Этот документ должен объяснить заказчику – какой бизнес-результат он получит от внедрения «1С:ERP», в какие сроки это будет сделано, и за какие деньги.
И вот уже на этом предварительном этапе появляются первые риски – недооценка сложности задачи, которая в дальнейшем может быть фатальной.
Для того, чтобы как-то оценить объем предстоящей работы, проводится экспресс-обследование заказчика, в рамках которого специалист должен оперативно выявить специфику предприятия, её основные отличия от типового функционала программы.
Работа по экспресс-обследованию зачастую не оплачивается заказчиком, в лучшем случае он заплатит за проезд и проживание специалистов. То есть это затраты подрядчика, которые вполне могут никогда не окупиться, если заказчик выберет другого исполнителя. Затраты все стараются минимизировать, поэтому экспресс проводится в течение двух-трех дней, и здесь РПшнику может помочь лишь его опыт выполнения подобных проектов. Наилучший вариант, если РПшник сразу приходит на пресейл с готовым решением – то есть он не обследует заказчика, а предлагает ему свое решение и весь экспресс сводится к обсуждению обнаруженных разногласий.
Что же делать, если Вы столкнулись с новой задачей? Чаще всего варианты следующие:
- Если Вы добросовестный подрядчик, то имеет смысл пожертвовать деньгами и разобраться в деталях, проведя небольшой НИОКР за свои средства, даже если не продадите этот проект, возможно, этот опыт пригодится на других проектах.
- Если же подрядчик решает сэкономить, то он выставляет какую-нибудь цену, в надежде на то, что после начала работ удастся увеличить бюджет.
- Есть ещё один вариант – прописать в коммерческом предложении ограничения типовой системы и явно указать, что цена может быть увеличена после этапа проектирования, если будут обнаружены существенные потребности в доработках. Этот вариант хуже первого (заказчики любят фиксированные цены), но значительно лучше второго.
Концептуальное проектирование
Раньше этот этап часто называли этапом написания технического задания на внедрения системы. Но это неправильный термин. Техническое задание готовит заказчик, исполнитель же по этому заданию готовит проектное решение – первым этапом подготовки такого решения является написание концептуального проекта.
Концептуальный проект детально описывает на «человеческом языке» то, как заказчик будет работать в будущей системе. Этот документ пишется на основе моделирования требований Заказчика в базе «1С:ERP». При защите модели специалисты исполнителя показывают ответственным лицам заказчика как работает программа. Демонстрация проходит с использованием реальных данных заказчика (небольшой выборки).
Если в процессе моделирования были обнаружены расхождения типового функционала с потребностями заказчика, то вот здесь уже, на следующих этапах, исполнитель пишет техническое задание на доработку системы. Само по себе такое ТЗ малоинтересно заказчику, так как он может не разбираться в технических деталях работы системы.
Итогом этапа концептуального проектирования является модель системы, в которой реализованы все автоматизируемые процессы заказчика и документ, в котором последовательно описано как в системе будут выполняться все операции Заказчика. Проще говоря, заказчик должен увидеть то, как он будет работать в системе и согласиться с этим. По тем местам, где требуется доработка типовой системы, в концептуальный проект вносится понятный эскиз/описание нового функционала.
Риски этого этапа внедрения «1С:ERP» следующие:
- РПшник может отнестись к работе легкомысленно и большую часть функционала программы не смоделировать в программе, а объяснить клиенту «на пальцах», проталкивая процесс на авторитете под лозунгом «не бойтесь, всё будет как надо». Как показывает практика, люди по разному понимают те или иные вещи, и такое объяснение может закончится тем, что на более поздних этапах проекта придется перепроектировать систему. Что можно тут посоветовать: заказчики, требуйте работающего примера в программе, а если это доработка – просите её детальное описание «на человеческом языке» в концептуальном проекте.
- Заказчик не понимает модель и боится уточнить важные для него детали: проектирование завершено, доработки произведены, документы подписаны, бюджеты потрачены и тут выясняется что «мы не можем так работать». Проблема эта, в основном, вызвана ложной боязнью потерять авторитет («я ФИНАНСОВЫЙ ДИРЕКТОР крупной конторы, КАК я могу не знать, что такое показатели бюджета и как они заполняются!?»). Как это компенсировать? Если есть подозрение, что заказчик не понимает модель, предложите ему самостоятельно повторить ваши действия в программе под вашим контролем, покажите какие отчетные формы будут в системе, как будут заноситься данные в систему. Это, конечно, более похоже на этап обучения, но если есть риск, что проектирование идет не так – почему бы не прибегнуть к нему уже сейчас, потом исправлять эти ошибки гораздо дороже. В общем, вовлекайте людей в процесс – пусть они перестанут быть зрителями и станут участниками.
- Заказчику всё равно, что написано в концептуальном проекте, потому что «это всё бумажки, а ты мне за результат ответишь – я деньги заплатил, сделай как надо». Этим грешат проекты, где заказчик выходец из «лихих 90-х». Сложная ситуация, в которой РП лучше сразу обострить отношения с заказчиком и, возможно, даже вернуть деньги за проект. Проекты внедрения «1С:ERP» не делаются без тесного взаимодействия с заказчиком и решений, зафиксированных в большом числе документов. В результате либо заказчик одумается и поймет, что «срубить денег» далеко не единственная цель исполнителя и к его опыту нужно прислушиваться. Либо с заказчиком лучше расстаться – может быть лучше ему (заказчику) продолжить считать на счетах – будет дешево и сердито. На практике, такая ранняя ссора иногда помогает – если у РП хватит уверенности выстоять под напором лихого клиента, он сочтет вас равным и будет помогать в работе. Серьезной ошибкой будет «отложить бумажки в сторону» — ни у заказчика, ни у вас не будет понимания как должна работать система, тоже самое проектирование вы всё равно будете делать, но только уже на этапе опытно-промышленной эксплуатации, весело бегая по граблям под злобные понукания заказчика.
Замечание от автора: В комментариях к прошлым статьям были вопросы – используем ли мы при проектировании такие решения как СППР. К сожалению пока не используем. Причина в том, что нет достаточного числа доступных учебных материалов о том, как это работает на практике. Мы (ВЦ «Раздолье») сейчас планируем провести исследование в этой части и результаты этого исследования использовать в своей работе, а также ознакомить с ними публику.
Написание технических заданий и доработка системы
После того как Вы защитили концепт, Вам нужно доработать систему под специфику заказчика, для этого нужно написать техническое задание разработчику. Здесь сразу возникает одна серьезная проблема – ТЗ пишется для разработчика в технических терминах, которые не всегда понятны заказчику. Но при этом заказчик должен быть уверен, что доработку будет сделана так, как он хочет. Для разрешения этой коллизии в ТЗ добавляется сценарий приемки клиентом нового функционала программы, который может содержать эскизы (формы объектов/отчетов и пр.), а также простое описание последовательности действий, которые пользователи должны совершать в доработанной программе и какие результаты они при этом должны получать. Описание пишется на языке пользователей.
Главная рекомендация здесь – не жалеть времени на написание сценариев приемки, так Вы сэкономите массу времени и денег.
Что касается самих доработок – не следует ими увлекаться, функционал «1С:ERP» содержит множество настроек, которые позволяют решить большинство задач клиента без доработок. У нас есть примеры внедрения «1С:ERP» на промышленных предприятиях, которые были выполнены совсем без доработок программы, или где доработки включали лишь отчеты и доп. обработки. В основном, как ни странно, это коммерческие предприятия, где традиционно много своих собственных «хотелок».
Замечания от автора: на проекте, где внедряются такие сложные программы как «1С:ERP» или «1С:Управление Холдингом» очень важно чтобы заказчик, даже в самом начале работ (на этапе проектирования), уже представлял себе функционал будущей программы, хотя бы на базовом уровне. Это снимет массу вопросов. Я здесь настоятельно рекомендую ещё до начала проекта провести обучение группы сотрудников клиента в учебных центрах «1С». Вы окупите эти затраты и запустите проект намного быстрее. В качестве компромиссного решения мы (ВЦ «Раздолье») подготовили учебные курсы по «1С:ERP», которые бесплатно раздаем нашим потенциальным клиентам (часть этих материалов доступна для скачивания на Инфостарте).
Как дорабатывать – побольше подписок на события, внешних отчетов, внешних обработок, использования функционала БСП.
Если стоит задача править регистры – рассмотрите вариант дублирования регистров и их заполнения нужными Вам данными в подписке на событие (не всегда получается, но пробовать стоит).
Если нужно упростить типовой функционал программы (спрятать или автоматически заполнять промежуточные документы) используйте документы-агрегаторы, которые сами не формируют проводки, а используют для этого типовые документы (но сразу подумайте о том, что будет, если документ будет перепроводиться/распроводиться – это ВАЖНО!).
При внедрении «1С:ERP» активно используйте типовой механизм доп. реквизитов объектов: в сочетании с правильным использованием подписок на события можно решить множество задач.
Риски этапа:
- Незнание типового функционала программы проектной командой.
- Неумение объяснять заказчику, как работать с типовым функционалом.
- Плохие сценарии приемки.
- Непродуманная логика пользовательской работы с новыми объектами конфигурации (изменение, перепроведение и т.п.).
- Вы ушли в свою нишу комфорта (технические детали) и забыли про «бумажки». Все доработки должны быть официально приняты заказчиком. Если есть проблемы при приемке, составляйте официальные протоколы разногласий, обсуждайте ситуацию и приходите к конечному решению. Не откладывайте задачи на потом (доделаем во время опытно-промышленной эксплуатации) – потом у Вас найдутся другие задачи.
Два первых пункта – это скорее риски этапа проектирования, но сработают они как раз на этапе доработки программы, когда исполнитель может на пустом месте начать городить пирамиды, с которыми клиенту потом жить и обновлять конфигурацию.
Замечание от автора: Были вопросы – используются ли на наших проектах средства автоматизированного тестирования, которые есть у «1С». Используем – конкретно я на одном из проектов писал сценарии нагрузочного тестирования. К сожалению, общей практики пока нет – причина в затратности этих работ, при том, что это не всегда нужно и заказчик не всегда готов оплачивать.
Написание инструкций на рабочие места
Данный этап иногда пропускается, но всегда это повод для обсуждения.
Что делается – понятно, перейдем сразу к тому, какие бывают проблемы:
- Инструкции пишет «технарь». Как итог – масса ненужных пользователю технических деталей, но отсутствует «взгляд сверху» на задачу; специфический язык изложения.
- В инструкции перечислены все возможные действия, скажем, с документом, но пользователю нужен описанный понятный сценарий, а не перечисление возможных настроек.
- Инструкции пишутся только на «хорошие» действия – создание объектов. В некоторых случая не менее важным является изменение объекта, его удаление и распроведение – и на что это может повлиять и что делать, если не получается.
- Вы опять забыли про «бумажки» — инструкции должны быть официально приняты заказчиком.
Что можно порекомендовать – пишите хороший концептуальный проект, тогда Вы сможете его использовать как шаблон для будущих инструкций. Пользуйтесь новыми технологиями – лучше один раз увидеть, как работает «1С:ERP», чем много раз прочитать об этом – пишите видеоролики, в качестве инструкций.
Обучение пользователей
Правильнее было бы назвать этот этап «Предварительное обучение пользователей».
Как показывает практика выполненных проектов автоматизации на «1С:ERP», до тех пор, пока пользователи не начнут реально работать с программой, они ничему серьезно не научатся. Причина этому простая: у пользователей есть своя текущая работа, от которой их никто не освобождал, поэтому к обучению они подходят по остаточному принципу и быстро всё забывают.
Не помогает здесь серьезно ни премиальный фонд, ни итоговые экзамены. Сильно увеличивать срок обучения тоже бессмысленно – может ещё и надоесть.
Что можно здесь посоветовать: проводите обучение на тех же примерах, на которых строили функциональную модель. Убьете двух зайцев: проверите, что ФМ жизненная (линейные пользователи скажут), пользователи убедятся на практике, что они смогут в программе работать.
Большего от этапа обучения желать не стоит.
Риски этапа:
- Нет практических занятий на данных клиента – пользователи не доверяют внедряемой системе.
- Затянуты сроки обучения – занятия мешают текущей работе, новая система заранее воспринимается негативно.
- Вы опять забыли про «бумажки» — процесс обучения должен проходить по утвержденным заказчиком программам, должно протоколироваться присутствие учеников на занятиях, их вопросы и кратко ответы на них, по итогам занятия у Вас должны быть подписи от всех учащихся или старших групп, о том что «обучение проведено».
Перенос начальных данных, интеграция с существующими системами заказчика
Содержание этапа понятно: нужно перегрузить данные из старых систем в новую, а также настроить обмен данными с программами, которые останутся у заказчика после внедрения «1С:ERP».
Какие риски здесь могут быть:
- Заказчик пообещал, что его сотрудники напишут выгрузку данных или настроят обмен на своей стороне, а Вам нужно лишь работать на стороне «1С:ERP». По факту получается, что сотрудники заказчика это делать не могут, не хотят, у них «много своей работы, да и вообще – кто здесь внедряет «1С:ERP» и за что мы заплатили такие деньги». Рассчитывайте на себя – закладывайте в проект риск того, что эту работу придется делать полностью Вам.
- Нет координации в работе – итоги выгружены, успешно загружены в «1С:ERP», но бабушка из ОМТС продолжает колотить новые документы в старую программу. По возможности заблокируйте ввод данных после их переноса. Если новая программа запускается параллельно с работающей старой, то предусмотрите оперативные отчеты сверки данных – особенно сверки начальных остатков в новой и старой программе (чтобы они ВДРУГ не поменялись).
- Ответственный сотрудник заказчика не проверил начальные данные, которые загрузили в «1С:ERP». Обещал, но не проверил – времени у него нет. Пишите протоколы переноса начальных остатков – с подписями ответственных лиц.
Опытно-промышленная эксплуатация
Мы строили-строили и, наконец, …
Прежде чем перейти к описанию этого этапа внедрения «1С:ERP», стоит разобрать некоторые комментарии к прошлым нашим статьям более подробно. Достаточно часто в комментариях нас (как партнера «1С») упрекали в дороговизне проектов, которая легко решается за счет привлечения фрилансеров или найма сотрудников штат.
Вот до этого этапа работ – это возможно. Можно нанять грамотных специалистов, которые хорошо обследуют предприятие, хорошо доработают программу, напишут инструкции, обучат пользователей. И в некоторых случаях на этом проект вообще заканчивается – дальше сопровождение. Мы неоднократно убедились, что без этапа опытно-промышленной эксплуатации – нет реального внедрения (и проекта с результатом!). Очень часто именно на этапе ОПЭ прекрасная картина неспешного хода проекта может мгновенно пойти прахом. И не помогает здесь поддержка руководства предприятия, высокое качество работ, низкая их цена и пр.. Для этого этапа важна квалификация и МАССОВОСТЬ команды исполнителя работ – сколько бойцов он сможет одновременно вывести в первую неделю-две работ.
Иллюстрация прошлой статьи картинками бойцов из WH40k имела существенную развлекательную составляющую, но в ней есть определенная правда, когда дело касается этапа опытно-промышленной эксплуатации – здесь Вы будете фактически воевать с пользователями клиента, вторгаясь в их уютные норы (зачеркнуто) рабочие места, ломая их привычный уклад работы. И численность вашего отряда в такой ситуации не менее важна, чем его квалификации.
Если Вы все правильно запроектировали и доработали, то из моей практики, при внедрении «1С:ERP», в начале этапа ОПЭ на 20-30 пользователей нужен один консультант. Это где-то первые две недели работы в программе, потом людей на проекте можно потихоньку сокращать.
Что мы делаем на ОПЭ – по факту в самом начале работ, мы должны обеспечить бесперебойную работу предприятия в новой программе, несмотря на низкую квалификацию пользователей (ещё не научились), несмотря на их возможный саботаж (такое встречается достаточно часто), несмотря на возможные ошибки прошлых этапов работы.
В процессе этого происходит постепенная передача знаний от консультантов к пользователям, люди на практике доучиваются, а Вы исправляете возможные ошибки в программе, что-то дорабатываете по месту.
Риски:
- МАЛО ЛЮДЕЙ В КОМАНДЕ. Вас просто задавят численностью обращений и Вы, со своим проектом автоматизации, будете мешать предприятию работать: если отгрузки встали, то хозяевам бизнеса всё равно кто виноват. Им нужно чтобы бизнес работал – все разборки они оставят на потом. Но до этого ПОТОМ нужно ещё дожить.
- Нет координации в команде – так как получить на проект безграничную команду у Вас не получится, то людей нужно правильно направлять. РП должен быть генералом, который следит за полем боя, но не лезет в гущу событий. Иначе Вы не заметите фланговый обход от сотрудников бухгалтерии и последующее Ваше окружение. А там уже и до капитуляции не далеко.
Что можно рекомендовать:
- Выводите достаточное количество людей, даже если у них нет нужной квалификации – пусть будут первой линией принятия обращений от пользователей – любой ИТэшник учится работать с программой быстрее рядового пользователя, поэтому совместите две задачи – разгрузите профи от рутины, прокачаете навыки новичков. Но профи на ОПЭ должны быть.
- Используйте автоматизированные средства фиксации обращений от пользователей – не забывайте об обращениях пользователей, анализируйте их, устраняйте причины наиболее частых обращений. Даже если пользователи не хотят писать электронные заявки, просите Ваших консультантов делать это за них.
- «Бумажки»: проводите регулярные (раз в неделю!) совещания с руководителями автоматизируемых предприятий – протоколируйте вопросы, проблемы, договоренности.
Замечания от автора: Часто спрашивают – можно ли использовать на проектах внедрения сложных систем (таких как «1С:ERP») методологию Agile. Есть даже доклады и статьи о блестящих результатах – бюджет меньше, заработало быстрее. Из своего опыта проектных работ скажу так: Agile используется тогда, когда Вы плохо запроектировали систему, плохо её доработали, плохо обучили пользователей, плохо перенесли остатки и все эти проблемы скопились на этапе опытно-промышленной эксплуатации. Тут Agile спасает – вешаете доску на стену, расписываете кучу входящих и поехали нарезать спринты. Вот отсюда берутся все рассказы о том, как сотрудники во франчах работают сверхурочно по ночам, сидят без денег (бюджеты прошлых этапов уже истрачены, а заканчивать проект нужно), делают работу абы как. Только раньше для этого не было красивого термина, теперь он есть – Agile.
Agile хорошо применим при работах по сопровождению уже внедренной системы – когда нужно что-то доделывать в спокойном режиме. На проектном внедрении, особенно «1С:ERP» — это лишь изящный термин прикрыть обычную штурмовщину.
Хотя есть одна методика Agile, которая может использоваться и в проектном внедрении, но только на этапе опытно-промышленной эксплуатации. Методика эта касается работы с обращениями пользователей – разбейте все поступающие от пользователей заявки по функциональным участкам, назначьте за каждый участок ответственного консультанта и следите, чтобы на каждом участке количество необработанных обращений не превышало определенного количества или отслеживайте допустимое время реакции на обращение. Если эти показатели на одном из участков стали хуже плановых, то дайте распоряжение консультантам других участков отложить свою работу и помогать отстающему, до тех пор пока ситуация не выправится. Но чтобы это заработало необходимо иметь хорошие средства электронной фиксации и обработки обращений.
Акты подписаны, пьем шампанское и едем отдыхать
Вот и всё – проект завершен, последние акты подписаны, и система зажила своей жизнью. Но остается вопрос её сопровождения. Как это делать правильно и чьими силами – я напишу об этом, когда буду писать о перспективах бизнеса франчайзи «1С».
На этом завершаю свой рассказ – чуть позже я напишу о причинах провалов проектов.
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2025 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
и
возможно стоит пояснить, в чем разница этих двух «ТЗ»?
Спасибо.
Для меня много полезного и в этой и в предыдущих публикациях.
(1) Называть требования заказчика ТЗ — это дань традициям, по сути это не ТЗ, а пользовательские требования к системе в целом. Оно не содержит деталей технической реализации. ТЗ на доработку исполнителя — это уже именно техническое задание, которое описывает ожидаемое решение на техническом языке.
Я для себя их называю требованиями заказчика (ТЗ заказчика) и ТЗ на доработку (ТЗ исполнителя).
(4) «ТЗ заказчика» ещё называют функциональными требованиями, такое термин часто самоочевиден для заказчиков «не технарей».
Концептуальное проектирование еще называют контрольным примером. Слышал такое определение как минимум на 3 проектах
У вас получается идеально сделать все этапы проекта, и не накапливается «хотелок», внезапных изменений в ТЗ, недообученных пользователей? Честь Вам и хвала в таком случае. Но честно говоря, не очень верится.
Каким инструментом по управлению проектами Вы пользуетесь?
ИМХО, вы не правильно трактуете методологию Agile в применении к внедрению систем 1С. Более правильна следующая трактовка: у заказчика нет денег на все хотелки разом, запускаем типовую «и поехали нарезать спринты». Каждый спринт — завершенный небольшой проект. Со всеми стадиями. Но короткий. Но проект. 🙂 И проектов в которых можно применить данную методологию — не много. И внедрение ERP на 100-500 арм (имхо) к ним не относятся.
(7) Так можно (типовая + доработки уже в процессе работы), но это хороший подход для собственного отдела ИТ, когда у тебя нет ограничений по бюджету проекта и доверительные отношения между пользователем и программистом, которые не портят деньги. А если есть бюджет, то при появлении хотелок вначале нужно понять из каких денег их делать, если бюджета нет, заключить допник, потом написать ТЗ, сделать, сдать заказчику. Обычные подрядные работы. Можно это назвать и Agile, но меня этому не так учили.
(6) По недообученным пользователям методику я привел, она относится к гибким методам управления работами, то есть можно считать её Agile (авторы, по крайней мере, считали).
Что касается доработок…
Скажу просто — чем хуже систему запроектироовали, тем больше будет на ОПЭ Agile, чем лучше, тем меньше. Если концепт вообще нереальный, то будет сплошной Agile переходящий в факап, суд с заказчиком и увольнение сотрудников — такое я тоже проходил.
А вообще методика мне нравится, но только для своего отдела ИТ и только после общего запуска программы в работу — допиливать по месту.
В работе пользуюсь тем, что есть у заказчика, к чему привыкли пользователи. Если ничего нет, использую Redmine с плагинами для регистрации инцидентов по почте и для… Agile. Я не всевидящий супермен, то, что в концепте будут неточности, я предполагаю, поэтому в работе эту методику по месту использую, но не предлагаю это как основной метод автоматизации крупных предприятий подрядным способом.
(6)
Запросами на изменения. Иногда запросы делаются за дополнительный бюджет, иногда за бюджет, скажем, опытно-промышленной эксплуатации.
(8)
Почему нет ограничений по бюджету? Как раз таки есть, и хотелки есть, но они могут не влазить в бюджет, а могут и влазить. Agile чем отличается от остального проектного управления? На мой взгляд ключевое: работающий функционал за итерацию. И итерации — равные. Таким образом, имеем бюджет проекта, имеем хотелки, определяем длину спринта и пошли в него напихивать хотелки. Заказчик может остановить проект после любого спринта и у него будет работающая система.
(11) Смотрите: под доработки выделили 100 рублей, у заказчика хотелок на 120 рублей и все страсть какие важные. С трудом утрясли увеличение бюджета до 120 рублей. Ситуация уже конфликтная — чтобы потом не было проблем при приемке работ и попытки допихнуть чего-то сверху, нужно писать хорошее ТЗ на доработки, рисовать эскизы системы, утверждать с заказчиком сценарии приемки. Подробное ТЗ — это уже не Agile (он как раз должен сократить накладные расходы проекта, за счет доверия между заказчиком и исполнителем).
Забили на ТЗ (денег на это нет, заказчик хочет быстрого решения), делаем быстро — заказчик на приемке говорит что он имел ввиду совсем другое, а с этим работать тяжело, давайте ещё доработок на 50 рублей, иначе работу не приму — я и так бабок заплатил больше чем планировал. Конфликт усугубился — вилка: делать за свои деньги в убыток (сразу вспоминается рассказы про франчей работающих по ночам за тарелку рисового супа), не делать и ругаться с заказчиком (вспоминаются рассказы о том как франчи ничего толком не делают, а кидают на деньги заказчика).
Я конечно несколько утрирую, но я РП и в мои задачи входит оценка рисков проекта. Я должен учитывать что дела могут пойти именно так (а они так идут достаточно часто).
(12)
Отлично, у него есть два пути, ограничится бюджетом или найти денег.
(12)
Совершенно с вами согласен!
(12)
А не затруднит привести ссылочку на методологию, где говориться, что при ведении проекта по гибкой методологии разработки не нужно ТЗ?
(13) Вот видел где-то перевод на русский. По моему авторы чуть ли не отцы основатели этой методики.
Если посмотреть там на Product backlog, то там есть что-то похожее на ТЗ в колонке How to Demo (как продемонстрировать). Но это не ТЗ. Да и вообще общий смысл Agile, который декларируется: уйти от бюрократии, чтобы наконец заняться делом.
При этом можно творчески переосмыслить методику Agile, добавить туда полноценные ТЗ и пр. Но тогда это просто подрядные работы на определенный объем работ — минипроект.
Тут ещё нужно понимать вот что: продавать хоть маленький проект, хоть большой — одинаково сложно. Зачем мне каждый раз тратить своё время на продажу очередного двухнедельного спринта, если я могу продать проект целиком на полгода работы.
Это только кажется, что маленькие проекты — это небольшие проблемы. Проблем там столько же, а бюджет меньше.
А можно разбить хотелки на итерации, и за одну итерацию вводить конечное количество функционала, как декларируется в Agile, или, к примеру, в 1С:ТБР.
Я не представляю, как без помощи системы управления проектами можно сдавать проекты на 100+ пользователей. Как, к примеру, в планируете людские ресурсы? Ведь это сотни, а то и тысячи человекочасов в месяц.
(14) По инструментам:
1. MS Project (куда без него).
2. Собственная разработка ВЦ «Раздолье» для учета времени работы сотрудников на проектах на основе 1С:Документооборот.
3. Как только проект переходит на этап ОПЭ обязательно требуется электронная система управления инцидентами — мне нравится Redmine, хотя работать приходилось с разными системами, главное чтобы они были и была возможность определенных настроек и отчетов.
(15)
Это функциональные требования пользователя, аналог ТЗ. Конечно, никто не будет требовать от вас оформления ТЗ по ГОСТ 34 в данном контексте. Но и без какого-то аналога ТЗ вы работать просто не сможете. Бюрократия там устраняется живым общением, но user story сохраняется оно ваше ТЗ. Иначе вы потом не сможете сдать спринт.
(15)
Устраним непонимание в терминах: что такое в вашем понимании полноценное ТЗ.
(15)
Вам не нужно продавать следующий спринт в понимании полноценной продажи с нуля. Тут зависит от заказчика, надо ему функционал, есть на него деньги — стартуем, нет — попрощались, пожали руки — рассчитались — разошлись.
Для вас основная сложность тут в прогнозировании загрузки. И конечно, при продажах проектов по водопадной методологии проще в части загрузки своих ресурсов и планирования.
(15)
Я где то утверждал обратное?
Спасибо Евгению, Андрею и Раздолью) Читается на одном дыхании. Во времена проектной работы сталкивался как «грамотно-православным» внедрением (с ТЗ, инструкциями, обучением, согласованием etc), так и с Agile внедрением))))
Вообщем инфа в статье 146%.
(18)
Изначально, речь зашла о том, что в проекте «под ключ», вы вдруг на ОПЭ начинаете запускать agile-методологию. Причем, сами же пишите, что это скопившиеся косяки. Но, agile, это методология ведения проекта в целом, а не на каком-то его этапе. Что собственно вы в этом посте и продемонстрировали, и на что я и пытался обратить ваше внимание в исходном посте.
(18)
Консенсус.
Блин, вот все проекты внедрения 1С, такие 1Сные, по другому и не сказать…
В каких предложениях собственно идет речь об управление сроками проекта, управлении рисками проекта, управлении людьми на проекте, управлении коммуникациями на проекте и прочих вещей которыми нужно управлять на проекте?
В статье только увидел, что РП нужно любить бюрократию и только она спасает проект и РП от тюрьмы или продажи собственной квартиры.
Извините, не могу не поправить: спринты, методология, методика это не Agile, это Scrum. Аgile это философия.
(21) Значит я написал правильную статью — не забывай про бюрократию на проекте и тогда у тебя не отберут квартиру и не посадят в тюрьму :).
Если серьезно, я позже напишу в комментариях о том, о чём Вы спрашиваете — всё это на самом деле гораздо проще (управление рисками, коммуникациями и пр.), чем об этом пишут в учебниках. Это отчасти всё та же бюрократия, отчасти искусство и психология (особенно в отношении рисков).
Довольно спорная статья… Вопросы и проблемы озвучены правильные и с нужного ракурса… но вот ответы. Ну не то, что бы совсем неправильные, а уж слишком однобокие и не охватывающие всех возможных вариантов. Готов предположить что у автора просто нет разнообразия в портфолио. Т.е. материал весьма хорош если надо выстроить методологию «с нуля» при достаточной лояльности заказчика. Но для реалий заказчика в РБ — этот материал много практической пользы не принесет.
Но в целом почитать стоит.. Хорошая «теоретическая» статья.
(24) Напишите о чем хотелось бы прочитать.
(23) кто сказал, что в учебниках об этом пишут сложно? куда уж роще собрать людей и составить реестр рисков, оценить их влияние на проект и вероятность совершения, а также перенести в план проекта задачи по работе с рисками. кто это делает? никто 🙂 риски описанные вами на различных этапах это лично ваш опыт, он богат спору нет, но ощущение что получили вы его болезненно, не открыв учебник 🙂 пишите еще 🙂
(26)
Даже прочитав учебник, все равно не получится идентифицировать многие риски пока их сам не прочувствуешь 🙂
(27) поэтому и прошу писать еще статьи 🙂
А не подскажете, какие программы наиболее, что-ли беспокойные.
Где больше напряжения?
Например, зуп и бух: Знаю, что бухгалтерию сопровождать, как правило проще, там все расслаблено более.
Т.е. по ЗУП часто авралы — все стоит — надо начислить ЗП и т.д. — напряжно.
В бух с этим проще.
В кадровом учете, как правило, тоже нет напряга.
В ERP больше напряга, чем в ЗУП?
(29)
А сами как думаете? 😉 Функционал ЗУП есть и в ERP, а также вагон и тележка другого функционала. 🙂
(30) ну я имею в виду другие подсистемы.
Просто с ЕРП не знаком.
Но, прочитал статью, тут где-то писалось, что прямо производство (или отгрузка) встала если прога заглючит?
Тогда, получается, надо, чуть не круглосуточно бдить и править?
Кстати, интересно, если блок ЗУП в 1 конфе, тогда при обновлении ЕРП надо и бухов выгонять из программы?
Или как вообще обновляется ЕРП?
И если заглючила конфа ERP на участке производства, что и бухов в расчетной группе может встать работа?
Или все-таки конфа зуп входит в поставку ЕРП, но это отдельная база?
(31)
Возможны оба варианта.
Да
(18) На лицо неверное использование Эджайла.
Проект целиком — Вы, как заказчик, понимаете к чему Вы придете в итоге.
Agile — Вы, как заказчик, понимаете только результат очередного спринта.
Неверно! План проекта все равно есть, с условными сроками и бюджетом. Все понимают к чему нужно прийти и сколько это будет стоить.
А вот выполнение работ идет спринтами, в конце каждого готовый к использованию продукт!
Объясню, лично я неоднократно сталкивался, когда на опытной эксплуатации выясняется, что все что было реализовано, на самом деле отличается от того что требуется — потому что ошиблись все (утрированно).
Даже была байка, что 80% требующегося функционала реализовывается во время опытной эксплуатации.
(26)
Мне очень интересно — кто-то начал использовать адекватно инструменты проектного управления (PMBok) просто прочитав учебник? Я четко помню, что после первого прочтения этот талмуд воспринимался как набор банальных и формальных инструкций (которые все мы с детства привыкаем читать наискосок и не выполнять).
Такое же отношение у меня многие годы было к секции «Консалтинг и корпоративные проекты» на партнерских семинарах фирмы «1С» — понять для чего так восторженно люди рассказывают об очередном документе (бумажке?), который можно составлять по ходу проекта.
И только начав сталкиваться с проектами где-то от 3тыс чел-часов началось осознание «мудрости» того, что называется «проектное управление» 🙂
(33)
Юрий, поясните, пожалуйста.
Вот что получается. Адекватный план проекта с понятными границами (в Ваших терминах «Все понимают к чему нужно прийти») по классической технологии появляется после первого этапа — он может называться ТЗ, Концептуальный проект, Функциональная модель…
Это значит первый этап при Agile и при классической технологии управления проектом — одинаковый.
Обучение, перенос данных — думаю, тоже этапы одинаково присутствующие при в обеих технологиях.
Получается, что разница между технологиями только в этапе разработки?
Но, если это так, то я не понимаю как поделить доработки типового функционала ERP-системы на спринты. В проекте внедрения же по каждой подсистеме не сотни тысяч часов разработки (обычно). Ну, пусть в каждой подсистеме даже пара тысяч часов разработки. Это примерно означает месяца 3 работы нескольких разработчиков. Чаще всего без большей части из этих доработок программа заказчику не особо нужна. Тогда как поделить на спринты этот объем? А если первый спринт будет длинной 2 месяца, то для чего запускать через 2 месяца полуфабрикатный продукт, который вызовет массу недовольства сотен пользователей (в том числе низкоквалифицированных «бабушек» на складах), чтобы через месяц повторить этот эксперимент еще раз?
Может все же Agile для разработки нового продукта больше предназначен?
Помогите разобраться.
(35)
Обучение, перенос данных — думаю, тоже этапы одинаково присутствующие в обеих технологиях.
Не совсем.
Задача получить в конце каждого спринта работающий участок.
Спринт не обязательно длится неделю, можно растянуть и на месяц. Два, три уже много.
По факту это мини проект, содержащий и проектирование, и разработку, и обучение, и эксплуатацию.
Например, внедряем учет по МСФО.
Каскадная модель:
1. Сделали план счетов
2. Сделали мэппинг
3. Сделали доработки
3. Перенесли данные
4. Создали отчеты.
5. Обучили персонал.
6. Выверяем.
7. Финиш.
Agile:
Спринт-1: учет ОС
1. Внесли счету учета ОС в ПС
2. Сделали мэппинг ОС и МЦ из РСБУ
3. Сделали доработки по учету ОС.
3. Перенесли данные по ОС.
4. Создали отчеты только в части ОС.
5. Обучили персонал.
6. Проверили что все ОК
7. Финиш спринта.
Спринт-2: учет ТМЦ
…
Спринт-3: учет займов
…
В конце каждого спринта мы получаем полностью работающий блок, понятный клиенту.
100% потребностей получаем в конце проекта. Т.е. проект это условно говоря 10 успешных спринтов.
Я не силен в производстве, поэтому дать вам совет, как делить на спринты ваши проекты, не смогу.
Это как шить лоскутное одеяло.
Я не знаю какие у вас проекты, но чаще всего много из того что было разработано как раз заказчику особо не нужно, или нужно, но нечто другое.
Конечно в проектах по распилу ни о каком эджайле и речи быть не может.
(36) и откату. Вот как раз сегодня к нам пришел очередной клиент, который внедрял 1С:ERP с продвинутым коллективом, который исповедовал аджайл, буддизм, сыроедение и воздержание. Несколько миллионов ушли коту под хвост, клиент хочет нормальный проект и наемных убийц.
С проектом мы ему поможем, со вторым пока нет — хотя это уже не первый клиент, который спрашивает об этом.
(36) А если серьезно: вот например запуск одной складской подсистемы у нас занимает иногда два-три месяца (в среднем). Как ее на спринты бить? По складам? А кому нужен один склад? Что в этом полезного для заказчика, кроме лишних затрат на ручную обработку данных об остатках (часть данных берем из одной программы, часть из новой и руками сводим 20 тысяч артикулов).
Ваша схема по МСФО хороша тем, что учет в РСБУ уже ведется, а вы частями настраиваете мэпинг. Но таких простых задач на пальцах посчитать. Сложные задачи не разъемны, потому и сложные. Запустите мне 20 складов на спринтах, или 5 цехов, или просто РСБУ: так и вижу картину:
— на этой неделе мы будем запускать 10 счет.
— но он же в корреспонденции?
— я сказал — только 10 счет!
(38)
По функционалу. Например, в первом спринте запускаем ручной ввод документов, во втором прикручиваем автоматизацию. Или совсем никак если клиент на это не готов. Agile не панацея. От степени готовности клиента к подобной методологии тут зависит тоже очень многое. И от проекта. Я в самом начале это тоже писал.
Интересная статья, но все таки где собственно само управление проектом внедрения системы, где управление рисками, деньгами, временем, ролями в команде. Не понятно из статьи, вы внедряете продукт или разрабатываете?
(36)
Хорошо. Понял.
Вопрос: если сейчас предприятие считает собирает МСФО в Экселе, то ему для чего-то нужен отдельно запущенный блок учета ОС по МСФО? Он ценность в Вашем примере иметь будет?
Т.е. суть вопроса — большинство проектов в нашей практике выглядят так, что люди как-то работают в наборе информационных систем и на бумаге. Как-то ведут учет, как-то планируют.
В таком случае какой ценностью будет для них реализованный отдельный участок подсистемы, если он только добавит в работу еще 1 информационную систему, усложнит работу и не улучшит качество информации (учетной, управленческой)?
При этом понятно, что внедрение можно (и часто нужно) делить на очереди. Скажем, запустили оперативный учет факта в том же производстве. Потом автоматизировали межцеховое планирование. Потом спустились в цех (если это нужно). Но каждая их из этих очередей крупнее спринта классического. Т.е., по сути, представляет собой проект (по классической технологии). А какую ценность может представлять для заказчика, скажем автоматизация какой-то части оперативного учета факта в производстве мне понять сложно.
(38)
Я больше по финансам специализируюсь.
Но если б был специалистом в MRP и WMS думаю смог бы организовать работу по спринтам.
— на этой неделе мы будем запускать 10 счет.
— но он же в корреспонденции?
— я сказал — только 10 счет!
В этом и проблема, вы думаете о том, как делать проект, но не думаете как решать проблему.
И кстати 10 счет вполне можно запустить) Знаете про 000 ?)
И я запускал отдельно и 10, и потом резервы по нелеквидам.
Чем крупнее проект, тем проще его дробить на мелкие участки.
(40)
коллега, цель статьи была немного отразить разницу между работами в классическом франчайзинге и в проектном бизнесе.
описать проектную технологию — зада другая.
а эта тема интересна?
(42)
Юрий, в принципе, можете не отвечать на мой вопрос — я понял.
понятно, что это может работать. при большом числе оговорок и высокой адекватности и заказчика и внедренца.
Мы постоянно сейчас сталикаваемся, похоже, с попыткой замаскировать неумение делать проекты красивымы словами про Agile, ТБР и т.д. Это и настораживает.
(43)интересна, но сложно воспринимать кашу, когда смешивается два различных направления, разработка ПО и внедрение ПО, такое ощущение что хватаются методики без должного понимания самой методики, но сама суть проектной технологии сводится на нет, остается только одно название. Может это такая фишка при внедрении программ 1С? Я так ни разу не работал на проектах, может поэтому и не могу толком понимать такие подходы.
(41)
А вот для этого внедренцам нужен мозг!
Нужно решать проблемы, а не добавлять системы усложняющие работу.
В начале проекта у вас есть список проблем.
Вы берете проблему, намечаете шаги по ее решению, делаете.
В конце спринта проблема должна быть решена.
Если вы делаете работу не решающую проблемы — ваша работа бесполезна.
(46) Мозг нужен всегда. То что Вы предлагаете, наверное имеет место быть, как некий небольшой проект (МСФО) или доработка уже работающей системы учета.
Пилить же большой проект на спринты…. — Вы привели в качестве примера правильную ситуацию — на проекте было плохо проведено моделирование, плохо обучили людей, плохо систему доработали, поэтому все работы пришлось делать на ОПЭ и тут Вам помог Аджайл.
По сути Вы повторили кусок моей статьи где я написал тоже самое, цитирую:
Да, это наверное тоже выход — хороший или нет, зависит от того запустилась ли система в работу. У меня такой опыт тоже есть (мне передавали убитые проекты), и, кстати, он вполне успешен в 50% случаев — один проект работает, но это был суровый опыт, который я не хочу повторять. И советовать его никому при комплексной автоматизации не буду. И помог тут скорее всего не Аджайл, а мои сильные переговорные качества и высокая квалификация консультантов и программистов, которых мне дали.
(47) Узнать хорошо было все сделано или плохо по каскадной модели можно только в конце проекта.
Agile позволяет получать нужный результат каждый спринт.
Правильная декомпозиция работ — основа успеха на проекте.
Приведу простой пример:
Agile — это автонавигатор, который говорит вам каждые пять минут — правильно ли вы едете.
Каскадная модель — это самолет. Вы в него сели, и куда вы прилетели, узнаете только в самом конце. И не факт что ваш багаж прилетел вместе с вами.
По каскадной модели, отследить что предприятие автоматизируется в правильном направлении очень сложно, т.к. по умолчанию подразумевается, что выполнение проекта — это правильно и полезно.
Можно угрохать 100млн и два года в описание моделей, разработку, тестирование — чтобы в конце понять, что полученное решение непригодно для промышленного использования. Либо требует еще 100млн, чтобы сделать так как надо.
Для автоматизации бизнеса, мое мнение, Agile подходит наилучшим образом, т.к. позволяет оперативно реагировать на изменения среды.
(48) Это сравнение совершенно не верно. Навигатор это классический проект — у вас есть маршрут (функциональная модель) и вы по маршруту едете. Если попадаете в пробки или встречаете ремонт дороги, перепланируете маршрут (оформляет запросы на изменение и меняете ФМ и концепт).
Аджайл — это езда от перекрестка до перекрестка (спринты), когда на каждом перекрестке Вы останавливаетесь и спрашиваете дальнейшую дорогу у окружающих (готовите новый спринт с заказчиком).
Наверное можно в обоих случая приехать туда куда нужно, но успешных внедрений1С:ERP на 150-200 рабочих мест я с помощью Аджайл не видел. А на проектной технологии у нас они есть.
(49) Нет. Каскадная модель это все таки самолет.
Мой навигатор мне регулярно предлагает сменить маршрут на более быстрый. И я могу в любой момент прекратить движение, если захочу припарковаться и дальше поехать на метро.
Самолет мне не даст над морем пересесть на корабль.
Я не видел и провальных. Отсюда можно сделать вывод, что внедренцы пока что бояться/не умеют использовать Эджайл.
Возможно стоит дернуть для консультаций внедренцев из ВайзЭвайс. Они вроде как используют скрам.
(45)
Давайте я Вам примерные параметры проекта назову, а Вы сами решите это внедрение или разработка и какой информации Вам не хватило в статье. Буду признателен за обратную связь.
Проект:
1. Бюджет в часах проекта в целом примерно 6.000 часов. Из них разработка (доработка типового функционала 1С:ERP) — примерно 2-3 тыс часов.
2. Продолжительность — 9 месяцев.
(51)То есть получается что более 50% функционала ERP не совместимо с предприятием или вы пошли по выгодному пути для вас, переписанием программы, вместо реинжеринга бизнес-процессов и документооборота под функционал программы?
(51)Про риски, вы что правда озвучивали такие риски заказчику, он не улыбнулся когда читал это?
(52)
Функционал ERP можно и нужно рассматривать как каркас. Кому то и его хватит, но всегда есть ньюансы. Например, взять функционал по ремонтам, вроде базовый функционал есть, но ТОиР все таки востребован. Или производственный модуль, вроде все есть, но отраслевая специфика порождает отраслевые решения. И это нормально! И опять таки, для осуществления реинжиниринга процессов, надо обладать соответствующими компетенциями.
ЗЫ. Много ли из даже крупных интеграторов обладает подобными компетенциями?
(54)Мне трудно представить что бы организация, позиционирующая себя как внедренец ERP систем не имела в своей команде специалистов по описанию и анализу бизнес процессов, как вообще тогда внедрять решение на сложном производственном предприятии. По крайне мере у меня не было такого опыта, что бы требовалось переписать 50% системы, мне приходилось приводить очень серьезные аргументы в пользу доработки системы, а не изменения бизнес-процесса на предприятии. Что значит рассматривать ERP как каркас?То есть в начале прихожу к заказчику и говорю это ERP система, а потом ему говорю, а вы знаете это не совсем ERP система, это каркас, в лучшем случае они покрутят у виска, в худшем получу по первое число, и буду думать как выкрутится.
(55) Так фишка в том, что ERP хотят вывести на уровень SAP — системы, в неудачном внедрении которой ни в коем случае нельзя признаваться 🙂
(50)
Это вы о том, что на полпути сказать: «Да пошло оно это ERP, нах… Дальше делаем на Комплексной Автоматизации или вообще на связке УТ+ЗУП+БП» ?
В целом аналогия подходящая, но и при полете на самолете в случае форс-мажоров можно и курс поменять, и вообще на другой аеропорт завернуть. А если изначально заказчик был хорошо выслушан, бизнес-процессы описаны очень точно, команда внедрения есть в полном составе и с достаточной компетенцией, то все будет хорошо — не нужны никакие смены курса и прочие «гибкости». Я считаю, что гибкие методологии (и даже тот же ТБР) на крупных внедрениях целесообразно применять, когда в головах у заказчика и его сотрудников бардак.
(57)
Даже если так. То в случае каскадной, заказчик это поймет только на этапе ОПЭ. Вывалив 100млн за разработку и прочую неосязаемую магию.
При Эджайле он это поймет значительно раньше. Или наоборот, поймет что ERP это то что надо.
Я неоднократно видел проекты, которые доводили до конца не потому что это требуется, а потому что вбухали немеряно бабла и нужно хоть какой -то результат показать. Такой проект считают успешным. Но действительно ли это так?
Если изначально проект был идеальный — то пофигу какая методология управления.
Да, только либо все равно в аэропорт, либо падать в надежде на чудо.
То есть всегда.
(59) Ну наверное я понимаю что такое ERP, раз обсуждаю эту тему. Вы только что описали бизнес процесс, который даже 10% не берет от всей стоимости проекта, а речь шла о 50% процентах переписания конфигурации, такое переписание может говорить о нескольких вещах, система почти полностью не подходит для предприятия, проектом в основном занимались программисты, со своим специфическим подходом, при внедрении, ну и последнее не смогли или не захотели найти другие решения, кроме как дописать.
(59)Что бы не писать так много, вспомнил один случай, из изучения проектными технологиями: руководитель, собирал свою команду, делил ее случайным образом на двое, выделял руководителя проекта, одна половина выступала в качестве заказчика, другая в качестве исполнителя, ложил на стол шоколадку, и говорил вот это бюджет проекта, вы должны внедрить решение, обе команды уходили и готовились к работе, каждый день собирал совещания, где вся команда во главе с руководителем решала поставленную задачу, для меня было очень поучительным, особенно когда шоколадка уже закончилась, а мы еще не достигли цели, но что бы получить еще одну шоколадку, нам нужно было очень сильно убедить руководителя в этом.
(60) я и не говорил, что это что-то огромное; даже наоборот, я говорил, что это маленький пример в качестве иллюстрации. А таких «кусочков» на предприятии может быть много. Я, к сожалению, не имею производственного опыта. Единственный мой проект с УПП на производственном предприятии практически не требовал доработок в производственном контуре — там было больше интеграции с другой 1С-системой, которую использовало дочернее предприятие. Может производство само по себе тема настолько простая, что коробочного функционала хватает за глаза, что бы планировать ресурсы и управлять затратами.
Но специфику работы никто не отменяет — всегда есть «серые» расчеты с поставщиками и потребителями, которые нужно детально учитывать в управленке и скрывать от налоговой в бухгалтерии; которые могут быть усугублены, если предприятие выпускает скажем алкогольную продукцию, когда фактически отгружает по оптовым ценам, а в бухгалтерии должно показывать как розничную продажу с приходом в кассу большей суммы денег, чем было реально получено, так как оптовые и розничные цены регулирует государство.
Плюс еще всегда бывает множество «хотелок» и «бантиков» от обычных сотрудников, которые руководство соглашается оплачивать — всякие WMS-штучки для кладовщиков, расширенный TMS-функционал для логистов, всякие парсеры сайтов с анализом цен для снабженцев, хитрые детализированные производственные и торговые планы с отчетом план-фактного анализа по принципу «все-в-одном» да еще и с обязательной сводной таблицей для управленцев, управление сетями дистрибуторов со сверками и с расчетами всяких ретро-бонусов для сбытовиков и так далее, и тому подобное…
(62)
Тема производства самая сложная, и по большому счету требует самых больших доработок, в прочь до полного переписывания производственных модулей, но такие доработки не делают в рамках проекта внедрения. Как правило на таких проектах основной целью стоит, запуск в кратчайшие сроки всей системы, зацикливание на каком то участке не позволительно, производственный процесс не будут останавливать из за какой то там ERP системы. Все доработке переносятся на окончание проекта, и если после этого все таки эти доработки будут нужны заказчику, то соглашается оплачивать, но до этого момента очень сложно убедить заказчика в доработке которая не является критической. По этим причинам все доработки относились к категории управления рисками.
(60) Вы не правильно поняли Евгения, весь проект — это 6 тыс. часов, из них 2 тыс. доработка. Это где-то 0,2% от тех трудозатрат, которые затратила на разработку 1С:ERP фирма 1С. На одном из партнерских семинаров озвучивали 1 млн 200 тыс. часов общая трудоемкость разработки этой системы. И это был по моему 2015 год, когда не было еще 2.2.
То есть мы меняем только 0,2% программы, остальной функционал идет как есть.
(50) Договор заключают взрослые люди, поэтому предполагается что они понимают что хотят. Внедрение такой сложной системы на 1С:ERP на крупном предприятии — это в 100% случаев реорганизация бизнеса. А это обязывает иметь верный продуманный план всех мероприятий. Чем он лучше продуман, тем выше вероятность успешного проекта.
Если же я в такой проект пойду без плана, ориентируясь только на сиюминутные пожелания заказчика, то кончится это тем что работа меня сметет — пожеланий будет много, они будут противоречивые, заказчик потеряется сам, замотает меня и потом меня же обвинит в том что я не рассказал как правильно, потому что он мне заплатил.
Автоматизация заказчика, который сам не знает что хочет — это 100% факап. В случае проектной технологии я это пойму еще на этапе пресейла проекта, когда заказчик откажется согласовать технико-коммерческое предложение с конкретными требованиями к автоматизации. То есть заказчик в случае проектной технологии не потеряет ничего.
В случае Аджайла он в работу влезет, нарежет спринтов, сам запутается, запутает исполнителя и потом обвинит исполнителя в своем же бардаке.
Я знаком с опытом ВайзАдвайс, в том числе как заказчик (когда работал директором ИТ в штате), он вызывает у меня (и не только у меня) массу вопросов, но без их присутствия в дискуссии обсуждать это я не буду.
(64)причем тут 1С, я исходил из времени вашего проекта, 2тыч из 6тыч это очень много, еще можно понять когда доработка идет в процессе опытной эксплуатации, когда заказчик уже полностью понимает что дает ему система и что он еще хочет от этой системы, но на этапе внедрения…
(66) Цитирую Вас
Мы переписываем (а скорее дописываем под специфику заказчика) менее 1% программы. Доработка — это вообще не самая важная часть проекта. С выходом 2.2 при определенной политической воле вообще можно запуститься на типовой, даже на крупном заказчике.
Главный вопрос проекта — это как правильно использовать существующие 99,9% функционала и как заставить людей им пользоваться. Вот за это платят. Доработки — это бантики.
(65)
Это очень странно, ведь вы написали:
Вы не понимаете как работает Эджайл? Давайте тогда на этом остановимся.
С моей стороны наш диалог выглядит так:
Я: В автомобиле камаз есть большой кузов, щебень возим в нем.
Вы: Я решительно не понимаю как можно возить щебень в автомобиле. Я видел автомобиль, кажется феррари, там много щебня не помещается.
Нам нужно обязательно проложить рельсы и возить щебень в вагонах.
(68) Аналогия с камазом мне нравится — себе на дачу, только в камазе, а если в промышленном масштабе возить, то лучше по железной дороге — гораздо дешевле и более предсказуемо.
Что такое Аджайл я знаю, когда его дополняют проработанным концептуальным проектом, детальными ТЗ и пр. атрибутами обычной проектной технологии, получается просто поэтапный запуск программы в работу. Так тоже можно, но здесь есть возражение высоких накладных расходов на согласование каждой итерации работ с заказчиком. Которые Аджайл идейно должен исключать.
Ну и предметно, если вы говорите, что я не знаю что такое Аджайл:
1. Назовите аналог плана графика работ в Аджайле? Заказчик всегда хочет знать в какой срок он получит работающую программу.
2. Назовите аналог бюджета проекта в Аджайле? Заказчик еще больше хочет знать сколько всего денег он заплатит — большинство серьезных заказчиков вообще выставляют проекты на торги — им нужна конечная фиксированная цена работ.
3. Назовите аналог концептуального проекта и функциональной модели в Аджайле? Productlog — не тянет, классически — это обычный список задач.
Я еще могу накидать таких вопросов, но ограничусь этими, наиболее важными.
(67)
Вы меня запутали, то одно пишите то другое. Может уже определитесь в цифрах. Если обсуждаем проекты, то и надо озвучивать цифры по проекту, а не переиначивать.
(68)
Может тогда вернемся к истории, для чего собственно разрабатывали эти методики, для управления проектами или все таки для снижения рисков, конфликтов между командами проекта?
(55)
Описывать процесс это одно, а но проводить его реинжиниринг совсем другое. Вот вы например точно уверены, что можете менять любые процессы у заказчика с ответственностью за результат? Т.е. говорить заказчику, что его процесс неправильно устроен и его надо поменять таким то образом. Точно уверены?
В основном изменения касаются наличия денег на это. Процесс поменять бывает проще, особенно если он не основной и его изменение функционально ничего не ломает.
Зачем утрируете? Если бы все было бы замечательно, то не появлялось бы отраслевых решений. Не было бы отдельных конфигураций по функциональным областям, как то ТОиР, УАТ и несть им числа. Все было бы в одной конфиге. Но реальность другая.
(72)
Да у верен, потому что у меня перед глазами два бизнес процесса, 1 который реализован у заказчика, оба процесса достигают одной цели, с целью экономии денег, я предлагаю тот процесс, который реализован в системе, заказчик выбирает тот который наиболее удобен для него и решат будет ли он финансировать это или нет. А еще больший эффект получается когда оба этих процесса просчитаны в денежном эквиваленте (но я за последние 10 лет не видел что бы применялись такие приемы работы)
(72)
Я не утрирую, а задаю конкретный вопрос, а если по другому, зачем заказчика заводить в заблуждение, крылатыми фразами, ради того что бы продать коробку, лучше сказать все как есть в самом начале, что бы заказчик понимал на что он идет, чем потом не выглядеть глупо перед руководством заказчика.
(69)
Пример: На проекте одна команда автоматизировала бизнес процесс, но заказчику захотелось детализировать это бизнес процесс до уровня который ему нужен, инициируется новы проект, с новой командой. Для головного проекта это идет как скрам. В скраме это идет как обычный проект. РП головного проекта следит что бы проект скрама не вышел за пределы своей области, в противном случае возникнет конфликт и риски нарушений в головном проекте
(74) Ну я и называл бы это проект с несколькими очередями запуска. Но какое это отношение имеет к скраму, как его описывают его основатели и идеологи?
Так работать безусловно можно, но только крупные заказчики не любят проектов с плавающими бюджетами — для них это инвест проект, сумма которого серьезно согласуется, часто соласование бюджета занимает год (у нас недавно запустился проект, бюджет согласовывали два года, сумма проекта 50 млн.).
Я не противник Аджайла как инструмента, но в танковый бой с вилами не ходят — у каждого инструмента есть своя область применения. Скрам — это хорошая вещь для внутренней доработки уже запущенной системы — приладить по месту, сточить выступающие углы.
(75)Вы вообще не правильно поняли этот пример, это разные проекты со своими бюджетами и командами, разница в том что второй проект появился после частичного выполнения первого искрам нужен был чтобы исключить множества конфликтов и нестыковок по людям по целям и потокам данных на выходе, можно было и по-другому пойти но выбрали эту методику. Ни каких плавающих бюджетов не было
(76) Это проект в несколько очередей, скрам — это идеологически совсем другое, почитайте книгу, которую я указал вначале. Там очень хорошее описание этого инструмента, с практическими примерами.
(73)
Похвальная уверенность
ФСА провести тот еще геморрой. Занимает кучу времени и ресурсов.
Естественно, не надо крылатых фраз и избитых слоганов. Но, всегда ли вы сразу имеете столько информации о заказчике, чтобы рекомендовать ему ту или иную систему или не дай бог вообще архитектуру системы?
(78)
Собственно сама система и ее архитектура обсуждается на этапе формирования проекта. Если я не могу рассказать заказчику об архитектуре системы, как я вообще могу ее внедрить. Если заказчик не знает какую систему он хочет, 1С:ERP или SAP/R3 к примеру, то в данном случае ему помогут бизнес-аналитики который смогут сформировать функциональные требования которым должна удовлетворять система, такой уровень выше моей компетенции, меня этому не учили, да собственно и не кому было учить
(77)Когда идти строго по книжкам, можно далеко уйти.
Несколько очередей проекта планируются на начальном этапе, когда уже есть определенные постоянные величины и возможно предсказать их изменения в будущем, один из примеров это 2 параллельных проекта, 1 проект автоматизация учета, 2 модернизация производства, когда после модернизации происходит изменения в производственных процессах, В 1 проекте нужно учесть, что к определенному моменту по требуется пойти по другому плану, при этом основной план так же будет в действии, в результате получается 2 очереди 1 проекта.
(69) Вы хотите прям строго следовать методичке? Универсального лекарства не бывает.
Тот же график, только несколько более укрупненный. И в котором значатся не «Разработка — Тестирование — Внедрение» а «Автоматизация А, Автоматизация Б, Автоматизация С»
Тот же бюджет. Вы все равно даете какую то оценку, все равно есть какие то рамки. Никто не начинает проекты без обозначенных рамок.
Вы все к методичке пытаетесь привязаться. Зачем?
Все модели, планы, бюджеты могут быть вполне обычными, с небольшими оговорками, чтоб по ним можно было работать используя Эджайл.
По моему опыту, почти любой проект в итоге скатывается в Эджайл, только если б эти подходы использовались изначально, можно было бы избежать лишних трат, лишнего геморроя, и кучи конфликтов.
Я вообще часто замечал, как сильно отличается понимание ситуации у РП, которые в шляпе дартаньяна ездят по ушам заказчика, и у проектной команды на которую сыпятся все шишки.
Каскадная модель была придумана теоретиками.
Эджайл — практиками.
Андрей, по поводу пункта 2 рекомендаций к рискам:
Вы не считаете, что привлекая недостаточно квалифицированных людей на проект существует вероятность, что те или иные этапы проекта будут выполнены с упущениями и для достижения поставленных целей придется привлекать сотрудников с достаточной компетенцией в этих вопросах, что увеличит затраты на выполнение проекта?
Опубликовали статью об опыте неуспешного проекта
Очень интересная и статья и дискуссия в каментах…
Несколько ИМХО со стороны заказчика уровня 300-500 р.м.:
1. примерно в 60-70%каментов сквозит Заказчик-идиот который ничего незнает и только генерит хотелки. С таким подходом, лучше не связывайтесь с таким заказчиком, рубить по легкому не получится это факт. Неприятно будет узнать, что таки Заказчик не идиот, просто у него своя точка зрения на тот результат который он хочет получить.
2. Нормальный Заказчик, прекрасно понимает, что любой франч сам не толком не знает всего устройства ЕРП и по каким граблям конфигурации он будет вести Заказчика, особенно когда речь идет о необходимости расширения базового фукнционала.
3. Заказчик испытывает серьезные сложности при подготовке ТЗ на свою автоматизацию на основе ЕРП (да и вообще продуктов 1С) т.к. фирма 1С не удосужилась снабдить своих потребителей (как франчей, так Заказчиков) какм-нибудь (пусть плохоньким) стандартом подготовки проектов автоматизации на основе своих продуктов. Приходится использовать действующие ГОСТы а они уж слишком обобщенные и не заточены на особенности платформы и методологии.
4. Стоимость проекта комплексной автоматизации, это для заказчика вообще проблема из проблем. С одной стороны давит 44ФЗ, с другой отсутствие понимания конкретного Исполнителя, а что ему собственно надо сделать.
5. Заказчик понимает что Исполнителю надо провести обследование, иначе он не получит конечный объем работ=стоимость проекта, но делать обследование бесплатно франч не может, а это новый проект на результаты которого нет стандарта, а следовательно доверя ни Заказчика, ни франча который потом выиграет сам проект. Это опять вопрос к производителю платформы…
6. Собственно занимаясь проектом, Исполнитель почему-то забывает, что Заказчик все это время ведет свой бизнес, поэтому мало вероятно, что он согласится в какой-то момент сломать все и сразу, и жить надеждой что спустя какой-то период у него наступит «счастье неземное» Для заказчика, более предпочтительна технология поэтапного запуска, причем с получением конкретного практического результата. И результат этот будет лучше если он будет для руководства по выше, а потом уже в деталях по ниже.
7. Многие Исполнители недооценивают закон Паретто (80/20). Зачастую доверие Заказчика можно заслужить быстрыми, простыми(отработанными), но показательными «победами», но мало кто разрабатывает инструментарий таких «побед».
…
Можно много что продолжить…
Но факт, такие проекты как внедрение ЕРП, делать без ТЗ и детального планирования — бред обреченный на неудачу.
Заказчик это партнер в проекте и если не понимать и недооценивать его задачи в этом проекте — проект обречен на неудачу…
Хочу присоединиться ко всему в Вашей статье,
Вы описали особенности и ход проектов у гос.заказчиков 1 в 1
Практически нечего добавить, ну если только повысить важность скорейшего начала работы пользователей в системе и получения ими навыков
Обычно я придерживаюсь следующих трех шагов
делаем ТЗ для договора
0. знакомимся — знакомимся и совместно формулируем желания предприятия (на этом этапе не нужно ничего предлагать нового)
1. схема — совместное описание схемы работы предприятия (Idef)
2. подготовка решения — совместное описание новой схемы работы (на этом этапе как раз можно предлагать дополнитльные улучшения, помимо изначальных)
3. завершение — пишем Тех.задание за заказчика и с ним уже проходим этапы коррекций — в нем уже все согласовано на предыдущих этапах
подписывание договора
по внедрению, аналогично:
0. знакомимся — с ключевыми сотрудниками подразделения, самыми уважаемыми и опытными
1. схема — схема процессов/интерфейсы + согласование + правка схемы + подписание (2-3-4 итерации)
2. подготовка решения — презентация — разработка — презентация
3. завершение — начало работы пользователей
эксплуатация/инструкции/сдача работ/перевод в ОПЭ
хочу отметить высокую важность наличия общей схемы работы предприятия на любом этапе работы — она как карта местности.
Еще удобно у себя иметь схему орг.структуры, с контактами руководителей/сотрудников, и комментариями к ним (характеры людей, их особенности и пр.)