0. 1СERP 1477 24.04.17 15:48 Сейчас в теме

Такие разные франчайзи. Часть вторая: Особенности реализации крупных проектов, Глава 2. Проектная технология при внедрении «1С:ERP»

Очередная статья о бизнесе франчайзи 1С. Здесь мы постараемся рассказать о том, какой подход используется при относительно крупных проектах, в частности, при внедрении «1С:ERP», дадим описание этапов проекта, укажем, какие риски имеет каждый этап работ, расскажем, уместны ли при внедрении «1С:ERP» такие модные методики, как Agile, автоматизированное тестирование и пр. Автор статьи Андрей Мироненко.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. CheBurator 3399 24.04.17 18:54 Сейчас в теме
Техническое задание готовит заказчик, исполнитель же по этому заданию готовит проектное решение


и

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


возможно стоит пояснить, в чем разница этих двух "ТЗ"?
4. andironenko 630 24.04.17 19:29 Сейчас в теме
(1) Называть требования заказчика ТЗ - это дань традициям, по сути это не ТЗ, а пользовательские требования к системе в целом. Оно не содержит деталей технической реализации. ТЗ на доработку исполнителя - это уже именно техническое задание, которое описывает ожидаемое решение на техническом языке.

Я для себя их называю требованиями заказчика (ТЗ заказчика) и ТЗ на доработку (ТЗ исполнителя).
5. wanray 24.04.17 21:18 Сейчас в теме
(4) "ТЗ заказчика" ещё называют функциональными требованиями, такое термин часто самоочевиден для заказчиков "не технарей".
user927056; +1 Ответить
2. tailer2 24.04.17 19:03 Сейчас в теме
3. CheBurator 3399 24.04.17 19:05 Сейчас в теме
Спасибо.
Для меня много полезного и в этой и в предыдущих публикациях.
6. smirnov.es 25.04.17 03:59 Сейчас в теме
Концептуальное проектирование еще называют контрольным примером. Слышал такое определение как минимум на 3 проектах


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

У вас получается идеально сделать все этапы проекта, и не накапливается "хотелок", внезапных изменений в ТЗ, недообученных пользователей? Честь Вам и хвала в таком случае. Но честно говоря, не очень верится.

Каким инструментом по управлению проектами Вы пользуетесь?
9. andironenko 630 25.04.17 08:50 Сейчас в теме
(6) По недообученным пользователям методику я привел, она относится к гибким методам управления работами, то есть можно считать её Agile (авторы, по крайней мере, считали).

Что касается доработок...

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

А вообще методика мне нравится, но только для своего отдела ИТ и только после общего запуска программы в работу - допиливать по месту.

В работе пользуюсь тем, что есть у заказчика, к чему привыкли пользователи. Если ничего нет, использую Redmine с плагинами для регистрации инцидентов по почте и для... Agile. Я не всевидящий супермен, то, что в концепте будут неточности, я предполагаю, поэтому в работе эту методику по месту использую, но не предлагаю это как основной метод автоматизации крупных предприятий подрядным способом.
master555; +1 Ответить
10. 1СERP 1477 25.04.17 09:32 Сейчас в теме
(6)
Запросами на изменения. Иногда запросы делаются за дополнительный бюджет, иногда за бюджет, скажем, опытно-промышленной эксплуатации.
7. DAV 25.04.17 05:40 Сейчас в теме
Из своего опыта проектных работ скажу так: Agile используется тогда, когда Вы плохо запроектировали систему, плохо её доработали, плохо обучили пользователей, плохо перенесли остатки и все эти проблемы скопились на этапе опытно-промышленной эксплуатации. Тут Agile спасает – вешаете доску на стену, расписываете кучу входящих и поехали нарезать спринты.

ИМХО, вы не правильно трактуете методологию Agile в применении к внедрению систем 1С. Более правильна следующая трактовка: у заказчика нет денег на все хотелки разом, запускаем типовую "и поехали нарезать спринты". Каждый спринт - завершенный небольшой проект. Со всеми стадиями. Но короткий. Но проект. :) И проектов в которых можно применить данную методологию - не много. И внедрение ERP на 100-500 арм (имхо) к ним не относятся.
8. andironenko 630 25.04.17 08:28 Сейчас в теме
(7) Так можно (типовая + доработки уже в процессе работы), но это хороший подход для собственного отдела ИТ, когда у тебя нет ограничений по бюджету проекта и доверительные отношения между пользователем и программистом, которые не портят деньги. А если есть бюджет, то при появлении хотелок вначале нужно понять из каких денег их делать, если бюджета нет, заключить допник, потом написать ТЗ, сделать, сдать заказчику. Обычные подрядные работы. Можно это назвать и Agile, но меня этому не так учили.
11. DAV 25.04.17 09:40 Сейчас в теме
(8)
(7) Так можно (типовая + доработки уже в процессе работы), но это хороший подход для собственного отдела ИТ, когда у тебя нет ограничений по бюджету проекта и доверительные отношения между пользователем и программистом, которые не портят деньги. А если есть бюджет, то при появлении хотелок вначале нужно понять из каких денег их делать, если бюджета нет, заключить допник, потом написать ТЗ, сделать, сдать заказчику. Обычные подрядные работы. Можно это назвать и Agile, но меня этому не так учили.

Почему нет ограничений по бюджету? Как раз таки есть, и хотелки есть, но они могут не влазить в бюджет, а могут и влазить. Agile чем отличается от остального проектного управления? На мой взгляд ключевое: работающий функционал за итерацию. И итерации - равные. Таким образом, имеем бюджет проекта, имеем хотелки, определяем длину спринта и пошли в него напихивать хотелки. Заказчик может остановить проект после любого спринта и у него будет работающая система.
12. andironenko 630 25.04.17 09:59 Сейчас в теме
(11) Смотрите: под доработки выделили 100 рублей, у заказчика хотелок на 120 рублей и все страсть какие важные. С трудом утрясли увеличение бюджета до 120 рублей. Ситуация уже конфликтная - чтобы потом не было проблем при приемке работ и попытки допихнуть чего-то сверху, нужно писать хорошее ТЗ на доработки, рисовать эскизы системы, утверждать с заказчиком сценарии приемки. Подробное ТЗ - это уже не Agile (он как раз должен сократить накладные расходы проекта, за счет доверия между заказчиком и исполнителем).

Забили на ТЗ (денег на это нет, заказчик хочет быстрого решения), делаем быстро - заказчик на приемке говорит что он имел ввиду совсем другое, а с этим работать тяжело, давайте ещё доработок на 50 рублей, иначе работу не приму - я и так бабок заплатил больше чем планировал. Конфликт усугубился - вилка: делать за свои деньги в убыток (сразу вспоминается рассказы про франчей работающих по ночам за тарелку рисового супа), не делать и ругаться с заказчиком (вспоминаются рассказы о том как франчи ничего толком не делают, а кидают на деньги заказчика).

Я конечно несколько утрирую, но я РП и в мои задачи входит оценка рисков проекта. Я должен учитывать что дела могут пойти именно так (а они так идут достаточно часто).
13. DAV 25.04.17 10:09 Сейчас в теме
(12)
Смотрите: под доработки выделили 100 рублей, у заказчика хотелок на 120 рублей и все страсть какие важные.

Отлично, у него есть два пути, ограничится бюджетом или найти денег.

(12)
С трудом утрясли увеличение бюджета до 120 рублей. Ситуация уже конфликтная - чтобы потом не было проблем при приемке работ и попытки допихнуть чего-то сверху, нужно писать хорошее ТЗ на доработки, рисовать эскизы системы, утверждать с заказчиком сценарии приемки.

Совершенно с вами согласен!

(12)
Подробное ТЗ - это уже не Agile (он как раз должен сократить накладные расходы проекта, за счет доверия между заказчиком и исполнителем).

А не затруднит привести ссылочку на методологию, где говориться, что при ведении проекта по гибкой методологии разработки не нужно ТЗ?
15. andironenko 630 25.04.17 10:25 Сейчас в теме
(13) Вот http://www.infoq.com/minibooks/scrum-xp-from-the-trenches видел где-то перевод на русский. По моему авторы чуть ли не отцы основатели этой методики.

Если посмотреть там на Product backlog, то там есть что-то похожее на ТЗ в колонке How to Demo (как продемонстрировать). Но это не ТЗ. Да и вообще общий смысл Agile, который декларируется: уйти от бюрократии, чтобы наконец заняться делом.

При этом можно творчески переосмыслить методику Agile, добавить туда полноценные ТЗ и пр. Но тогда это просто подрядные работы на определенный объем работ - минипроект.

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

Это только кажется, что маленькие проекты - это небольшие проблемы. Проблем там столько же, а бюджет меньше.
17. DAV 25.04.17 10:49 Сейчас в теме
(15)
Если посмотреть там на Product backlog, то там есть что-то похожее на ТЗ в колонке How to Demo (как продемонстрировать). Но это не ТЗ. Да и вообще общий смысл Agile, который декларируется: уйти от бюрократии, чтобы наконец заняться делом.

Это функциональные требования пользователя, аналог ТЗ. Конечно, никто не будет требовать от вас оформления ТЗ по ГОСТ 34 в данном контексте. Но и без какого-то аналога ТЗ вы работать просто не сможете. Бюрократия там устраняется живым общением, но user story сохраняется оно ваше ТЗ. Иначе вы потом не сможете сдать спринт.

(15)
При этом можно творчески переосмыслить методику Agile, добавить туда полноценные ТЗ и пр.

Устраним непонимание в терминах: что такое в вашем понимании полноценное ТЗ.

(15)
Тут ещё нужно понимать вот что: продавать хоть маленький проект, хоть большой - одинаково сложно. Зачем мне каждый раз тратить своё время на продажу очередного двухнедельного спринта, если я могу продать проект целиком на полгода работы.

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


(15)
Это только кажется, что маленькие проекты - это небольшие проблемы. Проблем там столько же, а бюджет меньше.

Я где то утверждал обратное?
18. andironenko 630 25.04.17 11:21 Сейчас в теме
(17) Мы сейчас по моему говорим об одном и том же, просто Вы называете это Agile, а я это называю минипроектами.

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

Сделаем небольшой SWOT анализ того, как делается одна и та же работа, если я буду использовать при внедрении программы методику Agile или проект под ключ целиком (при идеальном исполнителе):

1. Предсказуемость результата работ:
Проект целиком - Вы, как заказчик, понимаете к чему Вы придете в итоге.
Agile - Вы, как заказчик, понимаете только результат очередного спринта.

2. Предсказуемость бюджета проекта:
Проект целиком - Вы, как заказчик, знаете конечную цену проекта.
Agile - Вы, как заказчик, знаете только цену очередного спринта.

Противоположный вариант - исполнитель не справился:

1. Предсказуемость результата работ:
Проект целиком - Вы, как заказчик, имеет фиксированные условия работ и можете сравнить текущее состояние дел с договорными обязательствами.
Agile - Вы, как заказчик, не видите куда проект движется в целом (много и долго дорабатывали, но всё как-то кусками - в итоге система не работает).

2. Предсказуемость бюджета проекта:
Проект целиком - Вы, как заказчик, по подрядному договору можете взыскать всю потраченную сумму, несмотря на подписанные акты, если система в целом не заработала (прецеденты есть, всё зависит от желания заказчика судиться).
Agile - Вы, как заказчик, теряете или судитесь только за стоимость последнего спринта.

Теперь SWOT для исполнителя, но базовые требования другие - удовлетворить заказчика, заработать деньги.

При идеальном заказчике:

1. Удовлетворенность заказчика
Проект целиком - В договоре есть функциональные требования к системе, результат предсказуем.
Agile - Вы понимаете что заказчик хочет в рамках очередного спринта, но не понимаете итогового результата - глобальное (стратегическое) управление проектом полностью лежит на стороне заказчика.

2. Деньги::
Проект целиком - У Вас есть законтрактованная сумма дохода на длительный период, Вы можете спокойно распоряжаться своими ресурсами.
Agile - У Вас есть небольшой контакт и вы вынуждены постоянно миксовать сотрудников.

Противоположный вариант - плохой заказчик:

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

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

Вух... Можно выбирать.

Я это всё на своей шкуре испытал, в разных комбинациях. Поэтому предпочитаю не мельчить.
madreader; SmArtist; eeeio; Melenya; 1cWin; support; Dementor; Gluk_1C; 1СERP; recon; khomichevskaya; Krio2; +12 Ответить
20. DAV 25.04.17 12:04 Сейчас в теме
(18)
Мы сейчас по моему говорим об одном и том же, просто Вы называете это Agile, а я это называю минипроектами.

Изначально, речь зашла о том, что в проекте "под ключ", вы вдруг на ОПЭ начинаете запускать agile-методологию. Причем, сами же пишите, что это скопившиеся косяки. Но, agile, это методология ведения проекта в целом, а не на каком-то его этапе. Что собственно вы в этом посте и продемонстрировали, и на что я и пытался обратить ваше внимание в исходном посте.

(18)
Я это всё на своей шкуре испытал, в разных комбинациях. Поэтому предпочитаю не мельчить.

Консенсус.
33. Gureev 27.04.17 16:56 Сейчас в теме
(18) На лицо неверное использование Эджайла.

1. Предсказуемость результата работ:
Проект целиком - Вы, как заказчик, понимаете к чему Вы придете в итоге.
Agile - Вы, как заказчик, понимаете только результат очередного спринта.


Неверно! План проекта все равно есть, с условными сроками и бюджетом. Все понимают к чему нужно прийти и сколько это будет стоить.

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

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

Даже была байка, что 80% требующегося функционала реализовывается во время опытной эксплуатации.
35. 1СERP 1477 27.04.17 17:39 Сейчас в теме
(33)
Юрий, поясните, пожалуйста.
Вот что получается. Адекватный план проекта с понятными границами (в Ваших терминах "Все понимают к чему нужно прийти") по классической технологии появляется после первого этапа - он может называться ТЗ, Концептуальный проект, Функциональная модель...

Это значит первый этап при Agile и при классической технологии управления проектом - одинаковый.

Обучение, перенос данных - думаю, тоже этапы одинаково присутствующие при в обеих технологиях.

Получается, что разница между технологиями только в этапе разработки?

Но, если это так, то я не понимаю как поделить доработки типового функционала ERP-системы на спринты. В проекте внедрения же по каждой подсистеме не сотни тысяч часов разработки (обычно). Ну, пусть в каждой подсистеме даже пара тысяч часов разработки. Это примерно означает месяца 3 работы нескольких разработчиков. Чаще всего без большей части из этих доработок программа заказчику не особо нужна. Тогда как поделить на спринты этот объем? А если первый спринт будет длинной 2 месяца, то для чего запускать через 2 месяца полуфабрикатный продукт, который вызовет массу недовольства сотен пользователей (в том числе низкоквалифицированных "бабушек" на складах), чтобы через месяц повторить этот эксперимент еще раз?

Может все же Agile для разработки нового продукта больше предназначен?

Помогите разобраться.
36. Gureev 27.04.17 18:13 Сейчас в теме
(35)

Обучение, перенос данных - думаю, тоже этапы одинаково присутствующие в обеих технологиях.

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

Например, внедряем учет по МСФО.
Каскадная модель:

1. Сделали план счетов
2. Сделали мэппинг
3. Сделали доработки
3. Перенесли данные
4. Создали отчеты.
5. Обучили персонал.
6. Выверяем.
7. Финиш.

Agile:

Спринт-1: учет ОС
1. Внесли счету учета ОС в ПС
2. Сделали мэппинг ОС и МЦ из РСБУ
3. Сделали доработки по учету ОС.
3. Перенесли данные по ОС.
4. Создали отчеты только в части ОС.
5. Обучили персонал.
6. Проверили что все ОК
7. Финиш спринта.

Спринт-2: учет ТМЦ
...
Спринт-3: учет займов
...

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

Это как шить лоскутное одеяло.

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

Я не знаю какие у вас проекты, но чаще всего много из того что было разработано как раз заказчику особо не нужно, или нужно, но нечто другое.

Конечно в проектах по распилу ни о каком эджайле и речи быть не может.
37. andironenko 630 27.04.17 22:38 Сейчас в теме
(36) и откату. Вот как раз сегодня к нам пришел очередной клиент, который внедрял 1С:ERP с продвинутым коллективом, который исповедовал аджайл, буддизм, сыроедение и воздержание. Несколько миллионов ушли коту под хвост, клиент хочет нормальный проект и наемных убийц.
С проектом мы ему поможем, со вторым пока нет - хотя это уже не первый клиент, который спрашивает об этом.
Визард-Софт; +1 Ответить
38. andironenko 630 27.04.17 23:04 Сейчас в теме
(36) А если серьезно: вот например запуск одной складской подсистемы у нас занимает иногда два-три месяца (в среднем). Как ее на спринты бить? По складам? А кому нужен один склад? Что в этом полезного для заказчика, кроме лишних затрат на ручную обработку данных об остатках (часть данных берем из одной программы, часть из новой и руками сводим 20 тысяч артикулов).
Ваша схема по МСФО хороша тем, что учет в РСБУ уже ведется, а вы частями настраиваете мэпинг. Но таких простых задач на пальцах посчитать. Сложные задачи не разъемны, потому и сложные. Запустите мне 20 складов на спринтах, или 5 цехов, или просто РСБУ: так и вижу картину:
- на этой неделе мы будем запускать 10 счет.
- но он же в корреспонденции?
- я сказал - только 10 счет!
ShestakovVitaly; Визард-Софт; eeeio; deaddy64; Zabava_; Right tech; Solovyeff; Dementor; +8 Ответить
39. DAV 28.04.17 05:45 Сейчас в теме
(38)
А если серьезно: вот например запуск одной складской подсистемы у нас занимает иногда два-три месяца (в среднем). Как ее на спринты бить? По складам?

По функционалу. Например, в первом спринте запускаем ручной ввод документов, во втором прикручиваем автоматизацию. Или совсем никак если клиент на это не готов. Agile не панацея. От степени готовности клиента к подобной методологии тут зависит тоже очень многое. И от проекта. Я в самом начале это тоже писал.
42. Gureev 28.04.17 10:35 Сейчас в теме
(38)
Запустите мне 20 складов на спринтах

Я больше по финансам специализируюсь.
Но если б был специалистом в MRP и WMS думаю смог бы организовать работу по спринтам.

так и вижу картину:
- на этой неделе мы будем запускать 10 счет.
- но он же в корреспонденции?
- я сказал - только 10 счет!


В этом и проблема, вы думаете о том, как делать проект, но не думаете как решать проблему.

И кстати 10 счет вполне можно запустить) Знаете про 000 ?)
И я запускал отдельно и 10, и потом резервы по нелеквидам.

Чем крупнее проект, тем проще его дробить на мелкие участки.
44. 1СERP 1477 28.04.17 10:41 Сейчас в теме
(42)
Юрий, в принципе, можете не отвечать на мой вопрос - я понял.
понятно, что это может работать. при большом числе оговорок и высокой адекватности и заказчика и внедренца.

Мы постоянно сейчас сталикаваемся, похоже, с попыткой замаскировать неумение делать проекты красивымы словами про Agile, ТБР и т.д. Это и настораживает.
41. 1СERP 1477 28.04.17 10:31 Сейчас в теме
(36)
Хорошо. Понял.
Вопрос: если сейчас предприятие считает собирает МСФО в Экселе, то ему для чего-то нужен отдельно запущенный блок учета ОС по МСФО? Он ценность в Вашем примере иметь будет?

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

При этом понятно, что внедрение можно (и часто нужно) делить на очереди. Скажем, запустили оперативный учет факта в том же производстве. Потом автоматизировали межцеховое планирование. Потом спустились в цех (если это нужно). Но каждая их из этих очередей крупнее спринта классического. Т.е., по сути, представляет собой проект (по классической технологии). А какую ценность может представлять для заказчика, скажем автоматизация какой-то части оперативного учета факта в производстве мне понять сложно.
46. Gureev 28.04.17 10:44 Сейчас в теме
(41)
В таком случае какой ценностью будет для них реализованный отдельный участок подсистемы, если он только добавит в работу еще 1 информационную систему, усложнит работу и не улучшит качество информации (учетной, управленческой)?

А вот для этого внедренцам нужен мозг!
Нужно решать проблемы, а не добавлять системы усложняющие работу.

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

Если вы делаете работу не решающую проблемы - ваша работа бесполезна.
47. andironenko 630 28.04.17 12:25 Сейчас в теме
(46) Мозг нужен всегда. То что Вы предлагаете, наверное имеет место быть, как некий небольшой проект (МСФО) или доработка уже работающей системы учета.
Пилить же большой проект на спринты.... - Вы привели в качестве примера правильную ситуацию - на проекте было плохо проведено моделирование, плохо обучили людей, плохо систему доработали, поэтому все работы пришлось делать на ОПЭ и тут Вам помог Аджайл.
По сути Вы повторили кусок моей статьи где я написал тоже самое, цитирую:
Из своего опыта проектных работ скажу так: Agile используется тогда, когда Вы плохо запроектировали систему, плохо её доработали, плохо обучили пользователей, плохо перенесли остатки и все эти проблемы скопились на этапе опытно-промышленной эксплуатации. Тут Agile спасает – вешаете доску на стену, расписываете кучу входящих и поехали нарезать спринты.

Да, это наверное тоже выход - хороший или нет, зависит от того запустилась ли система в работу. У меня такой опыт тоже есть (мне передавали убитые проекты), и, кстати, он вполне успешен в 50% случаев - один проект работает, но это был суровый опыт, который я не хочу повторять. И советовать его никому при комплексной автоматизации не буду. И помог тут скорее всего не Аджайл, а мои сильные переговорные качества и высокая квалификация консультантов и программистов, которых мне дали.
48. Gureev 28.04.17 13:05 Сейчас в теме
(47) Узнать хорошо было все сделано или плохо по каскадной модели можно только в конце проекта.
Agile позволяет получать нужный результат каждый спринт.
Правильная декомпозиция работ - основа успеха на проекте.

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

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

Для автоматизации бизнеса, мое мнение, Agile подходит наилучшим образом, т.к. позволяет оперативно реагировать на изменения среды.
49. andironenko 630 28.04.17 13:34 Сейчас в теме
(48) Это сравнение совершенно не верно. Навигатор это классический проект - у вас есть маршрут (функциональная модель) и вы по маршруту едете. Если попадаете в пробки или встречаете ремонт дороги, перепланируете маршрут (оформляет запросы на изменение и меняете ФМ и концепт).

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

Наверное можно в обоих случая приехать туда куда нужно, но успешных внедрений1С:ERP на 150-200 рабочих мест я с помощью Аджайл не видел. А на проектной технологии у нас они есть.
Dementor; +1 Ответить
50. Gureev 28.04.17 15:03 Сейчас в теме
(49) Нет. Каскадная модель это все таки самолет.
Мой навигатор мне регулярно предлагает сменить маршрут на более быстрый. И я могу в любой момент прекратить движение, если захочу припарковаться и дальше поехать на метро.

Самолет мне не даст над морем пересесть на корабль.

но успешных внедрений1С:ERP на 150-200 рабочих мест я с помощью Аджайл не видел. А на проектной технологии у нас они есть.


Я не видел и провальных. Отсюда можно сделать вывод, что внедренцы пока что бояться/не умеют использовать Эджайл.
Возможно стоит дернуть для консультаций внедренцев из ВайзЭвайс. Они вроде как используют скрам.
57. Dementor 584 28.04.17 18:44 Сейчас в теме
(50)
Самолет мне не даст над морем пересесть на корабль.

Это вы о том, что на полпути сказать: "Да пошло оно это ERP, нах... Дальше делаем на Комплексной Автоматизации или вообще на связке УТ+ЗУП+БП" ?

В целом аналогия подходящая, но и при полете на самолете в случае форс-мажоров можно и курс поменять, и вообще на другой аеропорт завернуть. А если изначально заказчик был хорошо выслушан, бизнес-процессы описаны очень точно, команда внедрения есть в полном составе и с достаточной компетенцией, то все будет хорошо - не нужны никакие смены курса и прочие "гибкости". Я считаю, что гибкие методологии (и даже тот же ТБР) на крупных внедрениях целесообразно применять, когда в головах у заказчика и его сотрудников бардак.
58. Gureev 28.04.17 19:34 Сейчас в теме
(57)
"Да пошло оно это ERP, нах... Дальше делаем на Комплексной Автоматизации или вообще на связке УТ+ЗУП+БП"

Даже если так. То в случае каскадной, заказчик это поймет только на этапе ОПЭ. Вывалив 100млн за разработку и прочую неосязаемую магию.
При Эджайле он это поймет значительно раньше. Или наоборот, поймет что ERP это то что надо.

Я неоднократно видел проекты, которые доводили до конца не потому что это требуется, а потому что вбухали немеряно бабла и нужно хоть какой -то результат показать. Такой проект считают успешным. Но действительно ли это так?

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

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

То есть всегда.
user927056; mr_tuzlukov; +2 Ответить
65. andironenko 630 28.04.17 23:17 Сейчас в теме
(50) Договор заключают взрослые люди, поэтому предполагается что они понимают что хотят. Внедрение такой сложной системы на 1С:ERP на крупном предприятии - это в 100% случаев реорганизация бизнеса. А это обязывает иметь верный продуманный план всех мероприятий. Чем он лучше продуман, тем выше вероятность успешного проекта.
Если же я в такой проект пойду без плана, ориентируясь только на сиюминутные пожелания заказчика, то кончится это тем что работа меня сметет - пожеланий будет много, они будут противоречивые, заказчик потеряется сам, замотает меня и потом меня же обвинит в том что я не рассказал как правильно, потому что он мне заплатил.
Автоматизация заказчика, который сам не знает что хочет - это 100% факап. В случае проектной технологии я это пойму еще на этапе пресейла проекта, когда заказчик откажется согласовать технико-коммерческое предложение с конкретными требованиями к автоматизации. То есть заказчик в случае проектной технологии не потеряет ничего.
В случае Аджайла он в работу влезет, нарежет спринтов, сам запутается, запутает исполнителя и потом обвинит исполнителя в своем же бардаке.
Я знаком с опытом ВайзАдвайс, в том числе как заказчик (когда работал директором ИТ в штате), он вызывает у меня (и не только у меня) массу вопросов, но без их присутствия в дискуссии обсуждать это я не буду.
68. Gureev 29.04.17 00:33 Сейчас в теме
(65)
В случае Аджайла он в работу влезет, нарежет спринтов, сам запутается, запутает исполнителя и потом обвинит исполнителя в своем же бардаке.

Это очень странно, ведь вы написали:
А это обязывает иметь верный продуманный план всех мероприятий. Чем он лучше продуман, тем выше вероятность успешного проекта.


Вы не понимаете как работает Эджайл? Давайте тогда на этом остановимся.

С моей стороны наш диалог выглядит так:
Я: В автомобиле камаз есть большой кузов, щебень возим в нем.
Вы: Я решительно не понимаю как можно возить щебень в автомобиле. Я видел автомобиль, кажется феррари, там много щебня не помещается.
Нам нужно обязательно проложить рельсы и возить щебень в вагонах.
69. andironenko 630 29.04.17 08:34 Сейчас в теме
(68) Аналогия с камазом мне нравится - себе на дачу, только в камазе, а если в промышленном масштабе возить, то лучше по железной дороге - гораздо дешевле и более предсказуемо.

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

Ну и предметно, если вы говорите, что я не знаю что такое Аджайл:

1. Назовите аналог плана графика работ в Аджайле? Заказчик всегда хочет знать в какой срок он получит работающую программу.
2. Назовите аналог бюджета проекта в Аджайле? Заказчик еще больше хочет знать сколько всего денег он заплатит - большинство серьезных заказчиков вообще выставляют проекты на торги - им нужна конечная фиксированная цена работ.
3. Назовите аналог концептуального проекта и функциональной модели в Аджайле? Productlog - не тянет, классически - это обычный список задач.

Я еще могу накидать таких вопросов, но ограничусь этими, наиболее важными.
74. alex_sh2008 4 29.04.17 11:31 Сейчас в теме
(69)
Назовите аналог плана графика работ в Аджайле?

Пример: На проекте одна команда автоматизировала бизнес процесс, но заказчику захотелось детализировать это бизнес процесс до уровня который ему нужен, инициируется новы проект, с новой командой. Для головного проекта это идет как скрам. В скраме это идет как обычный проект. РП головного проекта следит что бы проект скрама не вышел за пределы своей области, в противном случае возникнет конфликт и риски нарушений в головном проекте
75. andironenko 630 29.04.17 12:41 Сейчас в теме
(74) Ну я и называл бы это проект с несколькими очередями запуска. Но какое это отношение имеет к скраму, как его описывают его основатели и идеологи?
Так работать безусловно можно, но только крупные заказчики не любят проектов с плавающими бюджетами - для них это инвест проект, сумма которого серьезно согласуется, часто соласование бюджета занимает год (у нас недавно запустился проект, бюджет согласовывали два года, сумма проекта 50 млн.).
Я не противник Аджайла как инструмента, но в танковый бой с вилами не ходят - у каждого инструмента есть своя область применения. Скрам - это хорошая вещь для внутренней доработки уже запущенной системы - приладить по месту, сточить выступающие углы.
Dementor; Gluk_1C; +2 Ответить
76. alex_sh2008 4 29.04.17 18:23 Сейчас в теме
(75)Вы вообще не правильно поняли этот пример, это разные проекты со своими бюджетами и командами, разница в том что второй проект появился после частичного выполнения первого искрам нужен был чтобы исключить множества конфликтов и нестыковок по людям по целям и потокам данных на выходе, можно было и по-другому пойти но выбрали эту методику. Ни каких плавающих бюджетов не было
77. andironenko 630 29.04.17 22:49 Сейчас в теме
(76) Это проект в несколько очередей, скрам - это идеологически совсем другое, почитайте книгу, которую я указал вначале. Там очень хорошее описание этого инструмента, с практическими примерами.
80. alex_sh2008 4 30.04.17 17:25 Сейчас в теме
(77)Когда идти строго по книжкам, можно далеко уйти.
Несколько очередей проекта планируются на начальном этапе, когда уже есть определенные постоянные величины и возможно предсказать их изменения в будущем, один из примеров это 2 параллельных проекта, 1 проект автоматизация учета, 2 модернизация производства, когда после модернизации происходит изменения в производственных процессах, В 1 проекте нужно учесть, что к определенному моменту по требуется пойти по другому плану, при этом основной план так же будет в действии, в результате получается 2 очереди 1 проекта.
81. Gureev 01.05.17 12:40 Сейчас в теме
(69) Вы хотите прям строго следовать методичке? Универсального лекарства не бывает.

1. Назовите аналог плана графика работ в Аджайле? Заказчик всегда хочет знать в какой срок он получит работающую программу.

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

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

Вы все к методичке пытаетесь привязаться. Зачем?

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

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

Каскадная модель была придумана теоретиками.
Эджайл - практиками.
hacsi; natterru; +2 Ответить
71. alex_sh2008 4 29.04.17 10:56 Сейчас в теме
(68)
Вы не понимаете как работает Эджайл? Давайте тогда на этом остановимся.

Может тогда вернемся к истории, для чего собственно разрабатывали эти методики, для управления проектами или все таки для снижения рисков, конфликтов между командами проекта?
14. smirnov.es 25.04.17 10:25 Сейчас в теме
Смотрите: под доработки выделили 100 рублей, у заказчика хотелок на 120 рублей и все страсть какие важные. С трудом утрясли увеличение бюджета до 120 рублей. Ситуация уже конфликтная - чтобы потом не было проблем при приемке работ и попытки допихнуть чего-то сверху, нужно писать хорошее ТЗ на доработки, рисовать эскизы системы, утверждать с заказчиком сценарии приемки.

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

Я не представляю, как без помощи системы управления проектами можно сдавать проекты на 100+ пользователей. Как, к примеру, в планируете людские ресурсы? Ведь это сотни, а то и тысячи человекочасов в месяц.
16. andironenko 630 25.04.17 10:31 Сейчас в теме
(14) По инструментам:
1. MS Project (куда без него).
2. Собственная разработка ВЦ "Раздолье" для учета времени работы сотрудников на проектах на основе 1С:Документооборот.
3. Как только проект переходит на этап ОПЭ обязательно требуется электронная система управления инцидентами - мне нравится Redmine, хотя работать приходилось с разными системами, главное чтобы они были и была возможность определенных настроек и отчетов.
19. spezc 587 25.04.17 11:54 Сейчас в теме
Спасибо Евгению, Андрею и Раздолью) Читается на одном дыхании. Во времена проектной работы сталкивался как "грамотно-православным" внедрением (с ТЗ, инструкциями, обучением, согласованием etc), так и с Agile внедрением))))
Вообщем инфа в статье 146%.
21. kolya_tlt 11 26.04.17 09:01 Сейчас в теме
Блин, вот все проекты внедрения 1С, такие 1Сные, по другому и не сказать...
В каких предложениях собственно идет речь об управление сроками проекта, управлении рисками проекта, управлении людьми на проекте, управлении коммуникациями на проекте и прочих вещей которыми нужно управлять на проекте?

В статье только увидел, что РП нужно любить бюрократию и только она спасает проект и РП от тюрьмы или продажи собственной квартиры.
Богатырев Артур; +1 Ответить
23. andironenko 630 26.04.17 12:29 Сейчас в теме
(21) Значит я написал правильную статью - не забывай про бюрократию на проекте и тогда у тебя не отберут квартиру и не посадят в тюрьму :).

Если серьезно, я позже напишу в комментариях о том, о чём Вы спрашиваете - всё это на самом деле гораздо проще (управление рисками, коммуникациями и пр.), чем об этом пишут в учебниках. Это отчасти всё та же бюрократия, отчасти искусство и психология (особенно в отношении рисков).
user927056; +1 Ответить
26. kolya_tlt 11 27.04.17 08:51 Сейчас в теме
(23) кто сказал, что в учебниках об этом пишут сложно? куда уж роще собрать людей и составить реестр рисков, оценить их влияние на проект и вероятность совершения, а также перенести в план проекта задачи по работе с рисками. кто это делает? никто :) риски описанные вами на различных этапах это лично ваш опыт, он богат спору нет, но ощущение что получили вы его болезненно, не открыв учебник :) пишите еще :)
27. DAV 27.04.17 10:22 Сейчас в теме
(26)
риски описанные вами на различных этапах это лично ваш опыт, он богат спору нет, но ощущение что получили вы его болезненно, не открыв учебник

Даже прочитав учебник, все равно не получится идентифицировать многие риски пока их сам не прочувствуешь :)
28. kolya_tlt 11 27.04.17 10:54 Сейчас в теме
(27) поэтому и прошу писать еще статьи :)
34. 1СERP 1477 27.04.17 17:24 Сейчас в теме
(26)
Мне очень интересно - кто-то начал использовать адекватно инструменты проектного управления (PMBok) просто прочитав учебник? Я четко помню, что после первого прочтения этот талмуд воспринимался как набор банальных и формальных инструкций (которые все мы с детства привыкаем читать наискосок и не выполнять).
Такое же отношение у меня многие годы было к секции "Консалтинг и корпоративные проекты" на партнерских семинарах фирмы "1С" - понять для чего так восторженно люди рассказывают об очередном документе (бумажке?), который можно составлять по ходу проекта.

И только начав сталкиваться с проектами где-то от 3тыс чел-часов началось осознание "мудрости" того, что называется "проектное управление" :)
22. soft-servis 14 26.04.17 09:42 Сейчас в теме
Извините, не могу не поправить: спринты, методология, методика это не Agile, это Scrum. Аgile это философия.
Vladimir Litvinenko; +1 Ответить
24. vova196 22 26.04.17 14:38 Сейчас в теме
Довольно спорная статья... Вопросы и проблемы озвучены правильные и с нужного ракурса... но вот ответы. Ну не то, что бы совсем неправильные, а уж слишком однобокие и не охватывающие всех возможных вариантов. Готов предположить что у автора просто нет разнообразия в портфолио. Т.е. материал весьма хорош если надо выстроить методологию "с нуля" при достаточной лояльности заказчика. Но для реалий заказчика в РБ - этот материал много практической пользы не принесет.

Но в целом почитать стоит.. Хорошая "теоретическая" статья.
25. andironenko 630 26.04.17 14:54 Сейчас в теме
(24) Напишите о чем хотелось бы прочитать.
29. inf012 27.04.17 11:38 Сейчас в теме
А не подскажете, какие программы наиболее, что-ли беспокойные.
Где больше напряжения?
Например, зуп и бух: Знаю, что бухгалтерию сопровождать, как правило проще, там все расслаблено более.
Т.е. по ЗУП часто авралы - все стоит - надо начислить ЗП и т.д. - напряжно.
В бух с этим проще.
В кадровом учете, как правило, тоже нет напряга.
В ERP больше напряга, чем в ЗУП?
30. DAV 27.04.17 11:41 Сейчас в теме
(29)
В ERP больше напряга, чем в ЗУП?

А сами как думаете? ;) Функционал ЗУП есть и в ERP, а также вагон и тележка другого функционала. :)
31. inf012 27.04.17 11:43 Сейчас в теме
(30) ну я имею в виду другие подсистемы.
Просто с ЕРП не знаком.
Но, прочитал статью, тут где-то писалось, что прямо производство (или отгрузка) встала если прога заглючит?
Тогда, получается, надо, чуть не круглосуточно бдить и править?
Кстати, интересно, если блок ЗУП в 1 конфе, тогда при обновлении ЕРП надо и бухов выгонять из программы?
Или как вообще обновляется ЕРП?
И если заглючила конфа ERP на участке производства, что и бухов в расчетной группе может встать работа?

Или все-таки конфа зуп входит в поставку ЕРП, но это отдельная база?
32. katenok86 243 27.04.17 14:04 Сейчас в теме
(31)
Или все-таки конфа зуп входит в поставку ЕРП, но это отдельная база?

Возможны оба варианта.
Кстати, интересно, если блок ЗУП в 1 конфе, тогда при обновлении ЕРП надо и бухов выгонять из программы?

Да
40. alex_sh2008 4 28.04.17 08:19 Сейчас в теме
Интересная статья, но все таки где собственно само управление проектом внедрения системы, где управление рисками, деньгами, временем, ролями в команде. Не понятно из статьи, вы внедряете продукт или разрабатываете?
43. 1СERP 1477 28.04.17 10:35 Сейчас в теме
(40)
коллега, цель статьи была немного отразить разницу между работами в классическом франчайзинге и в проектном бизнесе.
описать проектную технологию - зада другая.
а эта тема интересна?
45. alex_sh2008 4 28.04.17 10:41 Сейчас в теме
(43)интересна, но сложно воспринимать кашу, когда смешивается два различных направления, разработка ПО и внедрение ПО, такое ощущение что хватаются методики без должного понимания самой методики, но сама суть проектной технологии сводится на нет, остается только одно название. Может это такая фишка при внедрении программ 1С? Я так ни разу не работал на проектах, может поэтому и не могу толком понимать такие подходы.
51. 1СERP 1477 28.04.17 16:23 Сейчас в теме
(45)
Давайте я Вам примерные параметры проекта назову, а Вы сами решите это внедрение или разработка и какой информации Вам не хватило в статье. Буду признателен за обратную связь.

Проект:
1. Бюджет в часах проекта в целом примерно 6.000 часов. Из них разработка (доработка типового функционала 1С:ERP) - примерно 2-3 тыс часов.
2. Продолжительность - 9 месяцев.
52. alex_sh2008 4 28.04.17 17:00 Сейчас в теме
(51)То есть получается что более 50% функционала ERP не совместимо с предприятием или вы пошли по выгодному пути для вас, переписанием программы, вместо реинжеринга бизнес-процессов и документооборота под функционал программы?
54. DAV 28.04.17 17:17 Сейчас в теме
(52)
(51)То есть получается что более 50% функционала ERP не совместимо с предприятием или вы пошли по выгодному пути для вас, переписанием программы, вместо реинжеринга бизнес-процессов и документооборота под функционал программы?

Функционал ERP можно и нужно рассматривать как каркас. Кому то и его хватит, но всегда есть ньюансы. Например, взять функционал по ремонтам, вроде базовый функционал есть, но ТОиР все таки востребован. Или производственный модуль, вроде все есть, но отраслевая специфика порождает отраслевые решения. И это нормально! И опять таки, для осуществления реинжиниринга процессов, надо обладать соответствующими компетенциями.
ЗЫ. Много ли из даже крупных интеграторов обладает подобными компетенциями?
55. alex_sh2008 4 28.04.17 18:05 Сейчас в теме
(54)Мне трудно представить что бы организация, позиционирующая себя как внедренец ERP систем не имела в своей команде специалистов по описанию и анализу бизнес процессов, как вообще тогда внедрять решение на сложном производственном предприятии. По крайне мере у меня не было такого опыта, что бы требовалось переписать 50% системы, мне приходилось приводить очень серьезные аргументы в пользу доработки системы, а не изменения бизнес-процесса на предприятии. Что значит рассматривать ERP как каркас?То есть в начале прихожу к заказчику и говорю это ERP система, а потом ему говорю, а вы знаете это не совсем ERP система, это каркас, в лучшем случае они покрутят у виска, в худшем получу по первое число, и буду думать как выкрутится.
56. genayo 28.04.17 18:40 Сейчас в теме
(55) Так фишка в том, что ERP хотят вывести на уровень SAP - системы, в неудачном внедрении которой ни в коем случае нельзя признаваться :)
user927056; +1 Ответить
72. DAV 29.04.17 11:08 Сейчас в теме
(55)
Мне трудно представить что бы организация, позиционирующая себя как внедренец ERP систем не имела в своей команде специалистов по описанию и анализу бизнес процессов, как вообще тогда внедрять решение на сложном производственном предприятии.

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

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

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

Что значит рассматривать ERP как каркас? То есть в начале прихожу к заказчику и говорю это ERP система, а потом ему говорю, а вы знаете это не совсем ERP система, это каркас, в лучшем случае они покрутят у виска, в худшем получу по первое число, и буду думать как выкрутится.

Зачем утрируете? Если бы все было бы замечательно, то не появлялось бы отраслевых решений. Не было бы отдельных конфигураций по функциональным областям, как то ТОиР, УАТ и несть им числа. Все было бы в одной конфиге. Но реальность другая.
73. alex_sh2008 4 29.04.17 11:20 Сейчас в теме
(72)
Вот вы например точно уверены, что можете менять любые процессы у заказчика с ответственностью за результат? Т.е. говорить заказчику, что его процесс неправильно устроен и его надо поменять таким то образом. Точно уверены?

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


(72)
Зачем утрируете?

Я не утрирую, а задаю конкретный вопрос, а если по другому, зачем заказчика заводить в заблуждение, крылатыми фразами, ради того что бы продать коробку, лучше сказать все как есть в самом начале, что бы заказчик понимал на что он идет, чем потом не выглядеть глупо перед руководством заказчика.
78. DAV 30.04.17 07:12 Сейчас в теме
(73)
Да у верен

Похвальная уверенность

А еще больший эффект получается когда оба этих процесса просчитаны в денежном эквиваленте (но я за последние 10 лет не видел что бы применялись такие приемы работы)

ФСА провести тот еще геморрой. Занимает кучу времени и ресурсов.


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

Естественно, не надо крылатых фраз и избитых слоганов. Но, всегда ли вы сразу имеете столько информации о заказчике, чтобы рекомендовать ему ту или иную систему или не дай бог вообще архитектуру системы?
79. alex_sh2008 4 30.04.17 17:07 Сейчас в теме
(78)
Но, всегда ли вы сразу имеете столько информации о заказчике, чтобы рекомендовать ему ту или иную систему или не дай бог вообще архитектуру системы?

Собственно сама система и ее архитектура обсуждается на этапе формирования проекта. Если я не могу рассказать заказчику об архитектуре системы, как я вообще могу ее внедрить. Если заказчик не знает какую систему он хочет, 1С:ERP или SAP/R3 к примеру, то в данном случае ему помогут бизнес-аналитики который смогут сформировать функциональные требования которым должна удовлетворять система, такой уровень выше моей компетенции, меня этому не учили, да собственно и не кому было учить
59. Dementor 584 28.04.17 19:43 Сейчас в теме
(52)
То есть получается что более 50% функционала ERP не совместимо с предприятием или вы пошли по выгодному пути для вас, переписанием программы, вместо реинжеринга бизнес-процессов и документооборота под функционал программы?


Такая крупная система как ERP охватывает очень много контуров предприятия. Это вам не бухгалтерия, где поставил коробку, настроил загрузку документов из внешней системы, обучил пользователя комбинации кнопок для сдачи отчета и все! В ERP, КА, УПП, УТП и даже в более мелких УТ и УНФ есть много вещей, которые очень чувствительны к конкретным специфическим условиям работы - это и управление складом, и перевозки, и оформление продаж, и взаимоотношения с поставщиками... Если человеку с деньгами стукнула в голову идея: "а не открыть ли мне свечной заводик", то функционала коробки ему будет за глаза. Но чем дольше работает предприятие, чем дольше прыгает по разным граблям, сталкивается с конкурентами, недобросовестными покупателями/продавцами, рекетом, финансовыми кризисами с заморозками банковских счетов, с вороватостью и прочей недобросовесностью сотрудников, то все больше и больше они внедряют уникальных ноухау, которых в типовых решениях быть просто не может.

Маленький пример с последнего проекта. Этап доставки клиенту купленного товара. Документы, типовые печатные формы, отчеты - в принципе, типовое все устраивает (есть специфика с уникальными ПФ для сетевых магазинов, но тут и так все всем ясно и для примера это не принципиально). Но после того, как они десятки раз уже обжигались на сотни тысяч, то были изобретены ряд дополнительных проверок - на каждой печатной форме штрихкод, время печати и ФИО сотрудника; кладовщик сканирует накладную как факт, что он ее увидел и взял в работу именно в этом виде; после того, как все товары для отгрузки найдены и подготовлены к отгрузке - он делает повторное сканирование для перевода документа на новую стадию (или в случае недостач/пересортов должен изменить документ); далее уже логист по подтвержденным к отгрузке накладным делает задания водителям (контролируя, что бы в машине не было товара на слишком большую сумму); водители получив по накладным товар на складе в свою машину, должны сканированием штрихкода подтвердить, что у них все в наличии в полном составе; после возврата с рейса водители подходят к оператору, который вносит в базу результаты поездки и при необходимости формирует ведомость для сдачи собранной выручки в кассу и возвратную накладную для того, что бы кладовщик принял на баланс возвратный брак. Плюс из-за того, что операторы иногда вступали в сговор с водителями, еще был сверху дополнительный функционал закрытия дня склада с формированием сводной всех документов, их статусов и времени последней печати, что бы ответственный за склад бухгалтер мог сделать сверку с бумажными носителями (как раз тут время печати очень важно, так как ранее любили документы распечатать, переделать и перепечатать, а далее с этими двумя бланками водить за нос кладовщиков и бухгалтеров). И это я еще очень схематически обрисовал без десятков нюансов, которые касаются форм собственности клиентов, их местонахождения (городские магазины, рынки, или область), наличия КПК у некоторых экспедиторов, которые позволяли автоматизировать закрытие рейса без участия оператора, и так далее... Т.е. как бы типовое устраивает, но без сотен часов доработки в своем первозданном виде не нужно - так как сотрудники снова начнут массово и бесконтрольно обворовывать своего работодателя, а других людей на замену просто нет.
60. alex_sh2008 4 28.04.17 19:59 Сейчас в теме
(59) Ну наверное я понимаю что такое ERP, раз обсуждаю эту тему. Вы только что описали бизнес процесс, который даже 10% не берет от всей стоимости проекта, а речь шла о 50% процентах переписания конфигурации, такое переписание может говорить о нескольких вещах, система почти полностью не подходит для предприятия, проектом в основном занимались программисты, со своим специфическим подходом, при внедрении, ну и последнее не смогли или не захотели найти другие решения, кроме как дописать.
62. Dementor 584 28.04.17 21:42 Сейчас в теме
(60) я и не говорил, что это что-то огромное; даже наоборот, я говорил, что это маленький пример в качестве иллюстрации. А таких "кусочков" на предприятии может быть много. Я, к сожалению, не имею производственного опыта. Единственный мой проект с УПП на производственном предприятии практически не требовал доработок в производственном контуре - там было больше интеграции с другой 1С-системой, которую использовало дочернее предприятие. Может производство само по себе тема настолько простая, что коробочного функционала хватает за глаза, что бы планировать ресурсы и управлять затратами.

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

Плюс еще всегда бывает множество "хотелок" и "бантиков" от обычных сотрудников, которые руководство соглашается оплачивать - всякие WMS-штучки для кладовщиков, расширенный TMS-функционал для логистов, всякие парсеры сайтов с анализом цен для снабженцев, хитрые детализированные производственные и торговые планы с отчетом план-фактного анализа по принципу "все-в-одном" да еще и с обязательной сводной таблицей для управленцев, управление сетями дистрибуторов со сверками и с расчетами всяких ретро-бонусов для сбытовиков и так далее, и тому подобное...
63. alex_sh2008 4 28.04.17 21:57 Сейчас в теме
(62)
Может производство само по себе тема настолько простая, что коробочного функционала хватает за глаза, что бы планировать ресурсы и управлять затратами.

Тема производства самая сложная, и по большому счету требует самых больших доработок, в прочь до полного переписывания производственных модулей, но такие доработки не делают в рамках проекта внедрения. Как правило на таких проектах основной целью стоит, запуск в кратчайшие сроки всей системы, зацикливание на каком то участке не позволительно, производственный процесс не будут останавливать из за какой то там ERP системы. Все доработке переносятся на окончание проекта, и если после этого все таки эти доработки будут нужны заказчику, то соглашается оплачивать, но до этого момента очень сложно убедить заказчика в доработке которая не является критической. По этим причинам все доработки относились к категории управления рисками.
64. andironenko 630 28.04.17 22:56 Сейчас в теме
(60) Вы не правильно поняли Евгения, весь проект - это 6 тыс. часов, из них 2 тыс. доработка. Это где-то 0,2% от тех трудозатрат, которые затратила на разработку 1С:ERP фирма 1С. На одном из партнерских семинаров озвучивали 1 млн 200 тыс. часов общая трудоемкость разработки этой системы. И это был по моему 2015 год, когда не было еще 2.2.
То есть мы меняем только 0,2% программы, остальной функционал идет как есть.
66. alex_sh2008 4 28.04.17 23:50 Сейчас в теме
(64)причем тут 1С, я исходил из времени вашего проекта, 2тыч из 6тыч это очень много, еще можно понять когда доработка идет в процессе опытной эксплуатации, когда заказчик уже полностью понимает что дает ему система и что он еще хочет от этой системы, но на этапе внедрения...
67. andironenko 630 29.04.17 00:07 Сейчас в теме
(66) Цитирую Вас
50% процентах переписания конфигурации, такое переписание может говорить о нескольких вещах, система почти полностью не подходит для предприятия,

Мы переписываем (а скорее дописываем под специфику заказчика) менее 1% программы. Доработка - это вообще не самая важная часть проекта. С выходом 2.2 при определенной политической воле вообще можно запуститься на типовой, даже на крупном заказчике.
Главный вопрос проекта - это как правильно использовать существующие 99,9% функционала и как заставить людей им пользоваться. Вот за это платят. Доработки - это бантики.
70. alex_sh2008 4 29.04.17 10:48 Сейчас в теме
(67)
весь проект - это 6 тыс. часов, из них 2 тыс. доработка.

Мы переписываем (а скорее дописываем под специфику заказчика) менее 1% программы.

Вы меня запутали, то одно пишите то другое. Может уже определитесь в цифрах. Если обсуждаем проекты, то и надо озвучивать цифры по проекту, а не переиначивать.
61. alex_sh2008 4 28.04.17 20:25 Сейчас в теме
(59)Что бы не писать так много, вспомнил один случай, из изучения проектными технологиями: руководитель, собирал свою команду, делил ее случайным образом на двое, выделял руководителя проекта, одна половина выступала в качестве заказчика, другая в качестве исполнителя, ложил на стол шоколадку, и говорил вот это бюджет проекта, вы должны внедрить решение, обе команды уходили и готовились к работе, каждый день собирал совещания, где вся команда во главе с руководителем решала поставленную задачу, для меня было очень поучительным, особенно когда шоколадка уже закончилась, а мы еще не достигли цели, но что бы получить еще одну шоколадку, нам нужно было очень сильно убедить руководителя в этом.
53. alex_sh2008 4 28.04.17 17:11 Сейчас в теме
(51)Про риски, вы что правда озвучивали такие риски заказчику, он не улыбнулся когда читал это?
82. m.s.fog 16.05.17 08:07 Сейчас в теме
Андрей, по поводу пункта 2 рекомендаций к рискам:
Вы не считаете, что привлекая недостаточно квалифицированных людей на проект существует вероятность, что те или иные этапы проекта будут выполнены с упущениями и для достижения поставленных целей придется привлекать сотрудников с достаточной компетенцией в этих вопросах, что увеличит затраты на выполнение проекта?
83. 1СERP 1477 13.06.17 12:09 Сейчас в теме
Опубликовали статью об опыте неуспешного проекта http://infostart.ru/public/633012/
84. dddxddd 24.06.17 13:50 Сейчас в теме
Очень интересная и статья и дискуссия в каментах...
Несколько ИМХО со стороны заказчика уровня 300-500 р.м.:
1. примерно в 60-70%каментов сквозит Заказчик-идиот который ничего незнает и только генерит хотелки. С таким подходом, лучше не связывайтесь с таким заказчиком, рубить по легкому не получится это факт. Неприятно будет узнать, что таки Заказчик не идиот, просто у него своя точка зрения на тот результат который он хочет получить.
2. Нормальный Заказчик, прекрасно понимает, что любой франч сам не толком не знает всего устройства ЕРП и по каким граблям конфигурации он будет вести Заказчика, особенно когда речь идет о необходимости расширения базового фукнционала.
3. Заказчик испытывает серьезные сложности при подготовке ТЗ на свою автоматизацию на основе ЕРП (да и вообще продуктов 1С) т.к. фирма 1С не удосужилась снабдить своих потребителей (как франчей, так Заказчиков) какм-нибудь (пусть плохоньким) стандартом подготовки проектов автоматизации на основе своих продуктов. Приходится использовать действующие ГОСТы а они уж слишком обобщенные и не заточены на особенности платформы и методологии.
4. Стоимость проекта комплексной автоматизации, это для заказчика вообще проблема из проблем. С одной стороны давит 44ФЗ, с другой отсутствие понимания конкретного Исполнителя, а что ему собственно надо сделать.
5. Заказчик понимает что Исполнителю надо провести обследование, иначе он не получит конечный объем работ=стоимость проекта, но делать обследование бесплатно франч не может, а это новый проект на результаты которого нет стандарта, а следовательно доверя ни Заказчика, ни франча который потом выиграет сам проект. Это опять вопрос к производителю платформы...
6. Собственно занимаясь проектом, Исполнитель почему-то забывает, что Заказчик все это время ведет свой бизнес, поэтому мало вероятно, что он согласится в какой-то момент сломать все и сразу, и жить надеждой что спустя какой-то период у него наступит "счастье неземное" Для заказчика, более предпочтительна технология поэтапного запуска, причем с получением конкретного практического результата. И результат этот будет лучше если он будет для руководства по выше, а потом уже в деталях по ниже.
7. Многие Исполнители недооценивают закон Паретто (80/20). Зачастую доверие Заказчика можно заслужить быстрыми, простыми(отработанными), но показательными "победами", но мало кто разрабатывает инструментарий таких "побед".
...
Можно много что продолжить...
Но факт, такие проекты как внедрение ЕРП, делать без ТЗ и детального планирования - бред обреченный на неудачу.
Заказчик это партнер в проекте и если не понимать и недооценивать его задачи в этом проекте - проект обречен на неудачу...
85. kuril 52 28.09.17 16:08 Сейчас в теме
Хочу присоединиться ко всему в Вашей статье,
Вы описали особенности и ход проектов у гос.заказчиков 1 в 1

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

Обычно я придерживаюсь следующих трех шагов
делаем ТЗ для договора
0. знакомимся - знакомимся и совместно формулируем желания предприятия (на этом этапе не нужно ничего предлагать нового)
1. схема - совместное описание схемы работы предприятия (Idef)
2. подготовка решения - совместное описание новой схемы работы (на этом этапе как раз можно предлагать дополнитльные улучшения, помимо изначальных)
3. завершение - пишем Тех.задание за заказчика и с ним уже проходим этапы коррекций - в нем уже все согласовано на предыдущих этапах
подписывание договора

по внедрению, аналогично:
0. знакомимся - с ключевыми сотрудниками подразделения, самыми уважаемыми и опытными
1. схема - схема процессов/интерфейсы + согласование + правка схемы + подписание (2-3-4 итерации)
2. подготовка решения - презентация - разработка - презентация
3. завершение - начало работы пользователей
эксплуатация/инструкции/сдача работ/перевод в ОПЭ


хочу отметить высокую важность наличия общей схемы работы предприятия на любом этапе работы - она как карта местности.

Еще удобно у себя иметь схему орг.структуры, с контактами руководителей/сотрудников, и комментариями к ним (характеры людей, их особенности и пр.)
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Москва
зарплата от 130 000 руб. до 200 000 руб.
Полный день

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день

Консультант-методолог 1С
Краснодар
зарплата от 110 000 руб.
Полный день

Консультант 1 С
Краснодар
зарплата от 50 000 руб. до 150 000 руб.
Полный день