"Гнем" Waterfall

04.10.18

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

В прошлой статье (https://infostart.ru/public/898904/) мы поговорили о проблематике разных методик управления проектами – традиционный Waterfall и ныне модный Scrum. Но каких-то конкретных рекомендаций пока не дали. В рамках этой статьи поговорим о том, как же синтезировать эти подходы в то, что можно использовать в работе. Статья построена на примерах из практик ВЦ «Раздолье». Автор статьи директор по развитию ВЦ «Раздолье» Андрей Мироненко.

Введение (точнее продолжение)

По итогам рассмотрения обоих методов управления получилось, что Scrum (Agile) лучше использовать на внутренней автоматизации, Waterfall – при привлечении подрядчика. Но и в том и в том случае у нас остались незакрытыми определенные возражение:

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

Говорить в целом о какой-то универсальной «золотой» методике управления проектами не приходится – её нет. Но есть разумный подход к автоматизации, который я постараюсь изложить далее, в привязке к этапам проекта – напомню, что говорим мы конкретно о проектах внедрения «тяжелых» программ, таких как 1С:ERP.

Этап продажи проекта

Деньги на проект внедрения 1С:ERP выделяются не потому, что они у предприятия есть, а потому что в обмен на эти деньги предприятие планирует получить какую-то долговременную выгоду – снизить затраты, исключить потери от воровства и порчи, получить инструмент для принятия адекватных управленческих решений.

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

Следующая задача – это провести правильную декомпозицию этих целей до конкретных управленческих задач. Что это значит, рассмотрим на практике: предположим, что мы решили, что внедрение 1С:ERP поможет нам снизить затраты. А за счет чего снизятся эти затраты?

  1. Мы будем качественно контролировать наш производственный персонал, и они будут работать больше, а получать столько же.  Хорошая идея – но нужно подумать – а они точно согласятся работать больше? Или они у Вас уволятся? И где Вы найдете новых? Здраво оцените эти риски, прежде закладывать такую задачу в проект автоматизации.
  2. Мы будем качественно контролировать расход материалов. Вообще отлично – а у Вас есть актуальные нормативы расхода материалов? А как быстро Вы их актуализируете? А у Вас есть люди чтобы это сделать? Программа сама нормы не посчитает, и сама в себя их не занесет.
  3. Мы исключим закупку и производство неликвидов. А мы умеем прогнозировать сбыт? А с какой вероятностью? 1С:ERP пока этого не умеет.

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

И без этого ни чего у Вас не взлетит – хоть Agile это будет, хоть PMBoK – мы автоматизируем бизнес и здесь всё идет от реальных целей бизнеса.

Этап проектирования

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

Здесь важна квалификация консультанта или бизнес-аналитика, который должен грамотно подобрать из существующего в 1С:ERP, то необходимое заказчику. И правильно показать это – составить пример в демо-базе на данных заказчика и продемонстрировать систему лучшим образом: НЕ НУЖНО показывать то, как производят самолеты на данных мебельного завода – утрудитесь создать адекватный пример. Тогда не нужно будет писать бумажный талмуд ТЗ - люди уже увидели в системе себя, они согласуют и общее описание концепции автоматизации. Только не забудьте вписать в неё важные для Вас требования, без чего это решение не заработает.

Суммирую: идем от бизнес-требований, грамотно показываем примеры в демо-базе, согласуем проектное решение. Делаем всё быстро.

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

Что если заказчик не знает, чего хочет? Не в состоянии выставить бизнес-требования?

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

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

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

Этап адаптации системы (доработка типовой конфигурации)

Если мы не смогли уложить бизнес-требования в типовой функционал программы, то нужно дорабатывать 1С:ERP. Работаем также от «наглядности» – в первую очередь готовим эскизы новых экранных форм, эскизы будущих отчетов, описываем логику их работы. Согласовываем всё это с заказчиком – это основа будущего ТЗ на доработку. Под эту основу проектируем внутренние механизмы программы – код, регистры и т.п.

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

По сути это тоже квази гибкий подход к разработке – идем от приемки работ (то есть от будущего тестирования нашего решения). И тоже стараемся работать максимально наглядно.

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

Этап обучения пользователей

Повторю своё выступление на Infostart Event 2017 – не научишь пользователей на этапе обучения. Пока сами не начнут работать – не научатся. Поэтому наша задача на этапе обучения – убедить пользователей, что они смогут работать в программе – показываем им примеры их работы в 1С:ERP на их данных, чтобы они максимально быстро вникли в ситуацию – «заходишь сюда, делаешь так – вот твои пельмени, всё понял?». Не показываем общих вещей и всего сразу и всем одновременно – это не работает.

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

Тоже достаточно гибкий подход – без абстрактного преподавания обо всем и ни о чем.

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

Этап опытно-промышленной эксплуатации

Здесь целая поляна для Agile, если Вы плохо запроектировали систему. Если хорошо – место тоже найдется – рассмотрим следующий вариант организации техподдержки пользователей:

  1. Каждое обращение пользователей фиксируем.
  2. Дальше оно маршрутизируется на следующие очереди (трекеры):
    1. Это не ошибка – пользователь забыл, как работать.
    2. Это баг – но можно найти обходное решение.
    3. Это баг – работать так не можем.
  3. На обращения во всех очередях накладывается матрица приоритетов:
    1. Сделать сейчас – иначе нас отсюда выгонят к вечеру.
    2. Сделать до завтра – иначе нас выгонят завтра.
    3. Сделать в разумные сроки – указать какие.

По комбинации 2.a + 3.a быстро назначаем умного консультанта, удостоверяемся что пользователь понял и может работать дальше.

По комбинации 2.b + 3.a быстро даем обходное решение, контролируем что оно работает.

По комбинации 2.с + 3.a бежим сразу и всем составом – кто первый добежит. Таких ошибок должно быть минимальное количество – это критический просчет на этапе проектирования.

По комбинации 2.a + 3.b назначаем в очередь консультантам с высоким приоритетом, за час до конца дня удостоверяемся что такая очередь пуста – иначе бежим всем составом её разгребать.

По комбинации 2.b + 3.b даем обходное решение, пишем пользователю что его задача поставлена разработчикам. Контролируем завтра, что пользователь пользуется заплаткой.

По комбинации 2.с + 3.b ставим срочную задачу разработчикам, контролируем процесс её решения в течение дня.

По комбинации 2.a + 3.c назначаем в очередь консультантам со средним приоритетом, контролируем срок.

По комбинации 2.b + 3.c даем обходное решение, пишем пользователю что его задача поставлена разработчикам. Контролируем срок реализации.

По комбинации 2.с + 3.c ставим задачу разработчикам, срок реализации.

Выглядит замудренно, до тех пор, пока не используем визуализацию – столбцы «сейчас», «до завтра», «когда-то». Две группы столбцов – одна для консультантов, другая для разработчиков. Задачи в столбце «до завтра» отсортированы по приоритету. Задачи в столбце «когда-то» отсортированы по срокам. Смотрим на столбцы – начинаем делать со столбца «сейчас», дальше по приоритетам и срокам.

Примерно вот так:

Несколько «хинтов» из практик:

  1. Взятые в работу задачи как-то помечайте, но с доски не снимайте – чтобы видеть.
  2. Задачи могут переходить из столбцов – например, когда «когда-то» превращается в завтра.
  3. Чтобы не мучиться с назначением приоритетов (a-b-c) в процессе работы, заранее сегментируйте пользователей по приоритетности решения их проблем. Например, если это кассир и он не может принять иди выдать деньги, то это однозначно a. Потом, когда люди будут обращаться, приоритеты будут назначаться автоматически – Вы будете их лишь корректировать.

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

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

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

Вот Вам и квази канбан доски и ретроспектива.

Заключение

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

По идее, Вы должны сесть и написать табличку с тремя столбцами:

  1. Что полезного я получу от внедрения нового инструмента в работу.
  2. Что я потеряю при этом, какие риски появляются.
  3. Где я могу это применять.

А дальше заполняете и смотрите на результат. Если не получается «съесть» идею целиком, попробуйте сделать декомпозицию на отдельные виды работ – посмотрите, как можно их улучшить, комбинируйте с другими идеями. В умении взять лучшее и отказаться от ненужного и заключается талант специалиста.

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

АНОНС: В рамках первого дня Infostart Event 2018 состоится круглый стол, где мы "вживую" обсудим оба подхода к автоматизации - использование классического Waterfall и гибких методов управления проектами. Будем очень рады, если посетители круглого стола сами захотят выступить и рассказать о своем опыте работы - с чем они столкнулись на практике. Время круглого стола смотрите в программе мероприятий.

1С:ERP Проект внедрения Waterfall Agile

См. также

Адекватность РП и тимлидов. Часть 1. Вмешательство в процесс и влияние на результат

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    2808    0    biimmap    39    

38

Инструменты и процессы разработки 1С:Бухгалтерии

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    3826    0    mrXoxot    5    

29

Гибкая разработка 1С:Бухгалтерии

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3215    0    user1853337    8    

29

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Руководитель проекта Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    3187    0    1СERP    21    

31

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

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

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

05.07.2023    14875    0    ASchekachev    37    

55

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

Канбан и поставка ценности Бесплатно (free)

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

28.06.2023    6095    0    stnslv    5    

25

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

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

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

10.02.2023    5089    0    andironenko    2    

32

Тест для самопроверки руководителя проекта: как отличить падавана от рыцаря-джедая?

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5665    0    MariaTemchina    28    

22
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Valerych 05.10.18 13:24 Сейчас в теме
Но и в том и в том случае у нас остались незакрытыми определенные возражение:
...
Для Scrum – как контролировать общий прогресс по проекту в целом и как при итерационном внедрении учесть те требования, которые пока еще не вошли в бэклог (например, как заложить в спринтах по производству аналитику, которая понадобится позже – в спринтах по бюджетированию).


Scrum содержит в себе бэклог продукта и бэклоги спринтов.
По ссылке хорошо расписано различие между ними.
https://www.agilebasics.ru/backlogs/#section-1

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

Благодаря ведению бэклога продукта мы в состоянии не упускать из виду подобные архитектурные риски.

И немножко по самой статье.
В ней хорошо расписан гибридный метод, базирующийся на водопаде, с элементами гибкости.
Вероятно возможно решение, (переворачиваем), когда в основе метода будет Scrum с элементами водопада, при таком подъходе бэклог продукта включит в себя в качестве задач как упомянутые выше архитектурные риски, так и чуть ли не привычную структуру водопада, получив тем самым возможность контролировать общий прогресс по проекту в целом.
2. andironenko 797 15.10.18 13:51 Сейчас в теме
(1) В прошлой статье на эту тему я написал, что у бэклога есть одна проблема - мы не знаем, все ли задачи внесены в бэклог. То есть сам по себе бэклог (и Scrum в целом) не гарантирует каких-либо абсолютных преимуществ перед водопадом, а с точки зрения стратегии проигрывает водопаду - потому что в конкретной точке отдельного спринта мы не имеем инструментов чтобы понять насколько завершен весь проект. В водопаде я хоть плюс/минус понимаю что закончив этот этап у меня впереди этап такой-то и такой-то - и вот мой весь бюджет проекта, а вот сколько я уже съел и вот сколько у меня еще осталось и как это соотносится с реальностью.

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

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

Также есть вопросы по целостности архитектуры - поэтому как появляется потребность в регулярном рефакторинге архитектуры, чтобы новые решения очередного спринта выстраивались в единую архитектуру с прошлыми.
3. Valerych 17.10.18 16:17 Сейчас в теме
Если мы с нуля проектируем/разрабатываем уникальный продукт, метод водопада будет иметь подавляющее преимущество перед Scrum.

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

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

Одной из методик включающей в себя инкременты и этапность является Scrum.
Сработают и бэклоги и спринты и ролевое распределение участников и филосифия Agile.

например, как заложить в спринтах по производству аналитику, которая понадобится позже – в спринтах по бюджетированию


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

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

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

PPS. Почти так (разве что без употребления слова Scrum и без ряда его деталей) выглядит "второе внедрение" на месте первого неудачного, но научившего Заказчика быть реалистичнее в своих требованиях и ожиданиях (возможно силами другой команды, которой повезло не стать первой для такого проекта).
4. Winstoncuk 23.10.18 17:55 Сейчас в теме
Добрый день, коллеги!

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

Автор пишет:

Деньги на проект внедрения 1С:ERP выделяются не потому, что они у предприятия есть, а потому что в обмен на эти деньги предприятие планирует получить какую-то долговременную выгоду
– полностью согласен!

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

Вот эти цели проекта
- стоп!
В моем понимании это не цели проекта. У нас проект автоматизации, а цель любой автоматизации, в любой отрасли, при капитализме, она ровно одна - увеличение степени эксплуатации на одного работника.

Снижение затрат, это конечно хорошо, но это что-то эфемерное. Непонятно как выглядит снижение затрат за счет внедрения дорогущей системы, в нагрузку к которой я должен потом буду нанять еще и кучу ИТ спецов на поддержку и развитие этой системы. В чем для меня, как для бизнесмена здесь снижение затрат? Затрат на что? Как было в штате 50 сотрудников на первичке, так и осталось, изменилось лишь название программы в которой они работают. Не понимаю. Может мне дешевле за половину стоимости проекта нанять еще 10 дешевых бухгалтеров или экономистов и пусть дальше в Excel считают? Я, как бизнесмен, вообще не рассматриваю издержки как цель, моя цель увеличение прибыли, я на эту цель работаю. Конечно, чем ниже затраты, тем выше прибыль, но я не вижу как внедрение какой-то непонятной ERP мне увеличит прибыль. Если я до внедрения тратил миллон в год на ФОТ для бухгалтеров, а после стал тратить два с половиной миллиона - к бухгалтерам добавились еще ИТ-специалисты на поддержку и развитие ERP - это снижение затрат? Есть кейсы из реальной жизни, когда внедрение ERP привело к увольнению хотя бы 15% штата, без потерь качества продукта и с увеличением прибыли? Есть кейсы, когда внедрение ERP увеличило прибыль предприятия хотя бы на 30%? Причем именно внедрение системы к этому привело, а не что-то иное.

Сколько я теряю на воровстве и порче и столько стоит внедрение, сопровождении и развитии ERP системы? Может ERP при таком раскладе для меня в итоге будет еще большим злом? Как ERP сможет предотвратить кражи и порчу? Она может мне только помочь отследить причины постфактум, т.е. уже не является системой предназначенной для работы с кражами и порчей. Может система видеонаблюдения будет более эффективна? Или имеется ввиду, кража денег из бюджета компании? )) Ну, тут лучше простимулировать СБ на оперативную работу...

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

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

Давно читаю статьи ВЦ "Раздолье", всегда интересно и вызывает отклик. Поэтому и хочу воспользоваться случаем, так сказать. )) Возможно, я сейчас сморозил какую-то глупость, прошу тогда на нее указать, но мне хочется разобраться стоят ли за красивыми, "продающими" лозунгами реальные приобретения бизнеса от внедрений. Просто работая уже много лет в сфере 1С, я наблюдаю что после того как в компании что-то "внедряется", затраты только растут...

Спасибо.
8. 1СERP 3073 25.02.19 15:33 Сейчас в теме
(4)
"В моем понимании это не цели проекта. У нас проект автоматизации, а цель любой автоматизации, в любой отрасли, при капитализме, она ровно одна - увеличение степени эксплуатации на одного работника."

<< не очень понимаю, что имеется в виду. в статье написано то, с чем к нам приходят клиенты (если инициатором проекта является Генеральный директор или Собственник). От них как раз и звучит - "воруют", "дают информацию, которую невозможно проверить" - по сути, речь идет о потере контроля за какой-то частью бизнеса.

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

<< могу привести примеры:
1. Клиент занимается производством и продажей широкого ассортимента продукции. Понять сколько стоит изготовление единицы конкретной номенклатуры - не может. может оказаться, что исключение 10% ассортимента приведет к росту прибыли на 5% - а это очень не мало.
2. Большой клиент внедряет систему бюджетирования. Вводит больше сотни ЦФО и начинает детальный учет доходов и расходов. В результате просто закрывается несколько подразделений (отдаются их задачи на аутсорсинг). Сумму экономии сказать не могу, но она точно выше за год, чем стоимость проекта автоматизации.
...
Понятно, что многое из вышеописанного можно сделать и без информационной системы, но объем анализируемой информации может быть неподъемным и, это может быть более важным, если данные готовят люди в подразделениях, то насколько им можно верить? Систему многие воспринимают как некий объективный источник информации, которую сложно фальсифицировать, потому что сильно разделены точки ввода первичной информации, контроля, формирования на основе первичной информации, скажем, каких-то планов для других подразделений.

"Есть кейсы из реальной жизни, когда внедрение ERP привело к увольнению хотя бы 15% штата, без потерь качества продукта и с увеличением прибыли?"

<< есть. хотя очень единичные. Но сокращение людей совершенно не основной способ увеличения прибыльности в результате внедрения ERP-системы. Часть описал выше.

"Есть кейсы, когда внедрение ERP увеличило прибыль предприятия хотя бы на 30%? Причем именно внедрение системы к этому привело, а не что-то иное."

<< конечно нет. если бы внедрение приводило к увеличению прибыли на 30%, то стояла бы очередь огромная на проекты автоматизации. Для большинства организаций увеличение прибыли на пару процентов уже окупают проект внедрения. Но, даже если посчитать экономический эффект от внедрения системы трудно, то, скажем, эффект того, что Собственник начинает получать объективную информацию о деятельности предприятия сложно переоценить.
Что касается эффектов, к которым приводит именно система, а не что-то иное - тут тоже все не однозначно. У нас есть клиент, у которого очень большой объем работы с розничными сетями. До запуска ERP-системы они работали на нескольких базах в 7.7 (одна база не позволяла выполнить все задачи одновременно - падала). После внедрения заказчик пригласил консалтеров, которые разработали новую систему продаж. Сам заказчик признается, что в старой ИТ-системе реализовать рекомендации было невозможно. Приведет это к росту прибыли? Не знаю. Но без внедрения ERP-системы даже и проверить это было невозможно.

"Может ERP при таком раскладе для меня в итоге будет еще большим злом?"

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

По моему опыту, цель проектов может лежать и в росте прибыли, и в росте достоверности цифр. Когда приходишь к генеральному директору, а он говорит, что он не понимает сможет ли он выполнить предлагаемый ему крупный заказ, потому что не ясно хватит ли оборотки, какая реальная себестоимость у этого контракта. А сделают ли по той себестоимости, что обещали. То в такой ситуации речь идет не столько непосредственно о прибыли сколько о получении правдивой и адекватной информации от всех служб предприятия.
Или недавний разговор с одним очень немаленьким предприятием: "Вы работаете с прибылью?", "Да, но мы до конца не понимаем выгодны ли нам заказы от Государства. Ясно, что большая часть прибыли получается от экспортных контрактов". Т.е. прибыль есть, но понимания откуда именно она берется - очень смутное. И это очень опасно - небольшой дисбаланс в структуре заказов и нужно принимать решение, что делать (резать затраты или увеличивать, увольнять сотрудников или наоборот набирать, брать кредиты или торговаться с заказчиком по условиям и т.д.). Наверное, многие из этих данных можно собрать и руками силами различных служб, но насколько они будут достоверными и насколько их можно использовать при принятии решения - вопрос сложный.
Winstoncuk; +1 Ответить
9. Winstoncuk 28.02.19 12:07 Сейчас в теме
(8) Спасибо за ответ, некоторые вещи у меня в голове прояснились.

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

это и есть ответ на то что я имел ввиду в
цель любой автоматизации, в любой отрасли, при капитализме, она ровно одна - увеличение степени эксплуатации на одного работника
5. 1СERP 3073 25.10.18 11:36 Сейчас в теме
Друзья, мы сейчас готовимся к ERP Форуму http://1c.ru/bf/default.jsp
После него обязательно ответим на вопросы/комментарии
6. Leon29 25.02.19 06:42 Сейчас в теме
(5) Добрый день!
Решил напомнить об этом вопросе, поскольку тоже интересен ответ.
7. 1СERP 3073 25.02.19 14:59 Сейчас в теме
Оставьте свое сообщение