Как и в проекте, когда в начале проекта, заказчик не до конца понимая все последствия, подписывает документ с требованиями, налицо манипуляция со стороны подрядчика. Обратная ситуация столько же часто встречается, когда заказчик не раскрывает все сложности или детали в ТЗ, которые всплывают позже.
Согласен. Хотя манипуляция не заложена в самом Waterfall, иногда контрагенты манипулируют при его использовании. Как и в любом подходе, в принципе.
Вопрос не в том, что нравится мне. Каждый метод хорош в своих условиях.
При «водопадном подходе» в начале проекта фиксируются требования, подписывается ТЗ, которое становится формальным основанием позже отказать в изменении требований или попросить за изменение дополнительные деньги. В итерационном подходе такая уловка не применима.
Не понравилась одна эта фраза.
Зачем называть «уловкой» подход, который честно используют в другой методологии.
Если Вам нравится одна методология и не нравится другая — это Ваше дело. Вы можете использовать ее, описывать плюсы и минусы разных подходов, сравнивать их.
Но в этой фразе, на мой взгляд, Вы допускаете манипуляцию.
То есть следствием такой схемы расчета является гораздо более высокая сложность и ресурсоемкость плановых расчетов по сравнению с фактическими при агрегации даже обычных стоимостных показателей.
Это все про расчеты «по кругу», мы про них уже поговорили.
Что касается расчета плана сверху-вниз, то если на каком-то уровне такая схема не превращается в планирование снизу-вверх на основании норм и цен, а представляет собой лишь подгонку детализирующих лимитов под спущенные сверху сводные лимиты, то такое планирование является обычной профанацией. Поэтому такую схему нет никакого смысла рассматривать всерьез
Если Вы считаете, что планирование «сверху вниз» не должно существовать — это отдельная тема для разговора.
В процессе же планирования, в котором вся исходная нормативная база и алгоритмы расчета целиком и полностью завязаны на технологические особенности организации, для разработки качественного программного обеспечения для стороннего разработчика практически нет качественных источников информации для разработки технического задания.
Если коротко и без максимализма: разобраться с методикой планирования немного сложнее, чем с учетом. Так?
При планировании службы не просто вводят информацию, которую затем используют плановики, но и периодически ее уточняют и дополняют, причем зачастую письменно обосновывая необходимость тех или иных изменений. В результате плановики не просто обсчитывают экономические показатели по всем процессам предприятия, но и интенсивно взаимодействуют с отделами-поставщиками исходных данных для плановых расчетов.
Да, но это все по сути про рекурсивность расчетов «снизу-вверх/сверху-вниз».
1. Принципом отнесения данных к первичным (вводимым руками) или расчетным (вычисляемых компьютером). В учете первичными данными выступают преимущественно абсолютные значения показателей (количество потребляемых ресурсов, суммы продаж, суммы процентов по кредитам и т.п.), а в планировании — преимущественно относительные (нормы расхода потребляемых ресурсов, цены продаж, процентные ставки по кредитам т.п.).
Планируются часто и абсолютные показатели, и относительные.
И вычисления в планах действительно идут и снизу вверх (от детальных к сводным), и сверху вниз (от итоговых к детальных), и по кругу.
Хотя вот Вы про это и пишете:
4. В учете в подавляющем большинстве случаев используются последовательные расчеты вычисляемых показателей. В планировании зачастую невозможно обойтись без рекурсивных расчетов.
2. Учет всегда оперирует фактической информацией, которая является максимально полной и достоверной. При этом план всегда оперирует будущей информацией, которая по определению всегда недостоверна и фрагментарна.
Хороший вопрос, который, если получится, я рассмотрю в будущих публикациях. Сейчас в реал-таймовых ERP-системах очень важна информация, которая находится на границе между планом и фактом.
5. Учет представляет собой строго регламентированный процесс, регулируемый нормативными актами начиная с федеральных законов и заканчивая внутриведомственными инструкциями и стандартами. Для планирования отсутствует какая-либо регламентация со стороны государственных органов (за исключением государственных учреждений в рамках бюджетного процесса), в внутри организации процесс планирования в гораздо большей степени регулируется сложившимися практиками, чем внутренними нормативными актами.
И учет может быть управленческим, и планирование может быть государственным или регламентированным управляющей компанией. Здесь большой разницы нет.
В планировании работы в рамках всех процессов выполняется одними и теми же сотрудниками, обладающими знаниями по всем планируемым процессам организации.
Тем не менее, планы могут ходить «по кругу» между отделами, и отделы могут корректировать только свою часть, не разбираясь в других разделах.
У РП в таком случае нет ни таких полномочий, ни таких функциональных знаний. Я думаю, что такие решения должны приниматься коллективно членами управляющего комитета.
У РП практически никогда нет (и не должно быть) полномочий по построению самих бизнес-процессов.
Я имел ввиду, что он должен принять решение, какие процессы нужно моделировать, если оказывается, что их версий несколько (например, если оказывается, что реальные отличаются от тех, которые рассказывают подразделения). Каждый лишний анализ гэпов увеличивает трудозатраты аналитика, но вопрос «анализировать ли их» не должен стоять перед аналитиком. Ему ставят задачу другие люди (а точнее, руководитель проекта; а с кем он в свою очередь ее согласует, это его дело).
И что тогда моделировать? Оба варианта? А если расхождений сотни? Сколько версий процессов будет? Нет, фиксировать несоответствие и решать его надо сразу.
Я в комментариях не делал разницы между «моделировать», «выяснять» и «описывать».
Если Вы об этом — согласен.
Человека, который принимает решение о том, по какой версии бизнес-процессов нужно вести автоматизацию, если этих версий четыре (регламентированные; «как рассказали пользователи»; реальные, о которых никто не знает; те, которые могут получиться с учетом возможностей программного продукта) или больше.
Этот человек — не бизнес-аналитик (не тот, кто описывает эти процессы).
Вопрос был скорее в том, как описывать тогда, когда все вольно или невольно врут.
Как описывать — вопрос бизнес-аналитика.
А что описывать — вопрос руководителя проекта.
И ответ на него дается индивидуальный в каждой конкретной ситуации.
Аналитику нужно
1. Получить четкое задание на то, какие именно версии бизнес-процессов нужно смоделировать
2. Допустим, РП ставит задачу выяснить реальные бизнес-процессы, при условии что пользователи их честно не расскажут
3. Теперь аналитик в трудной ситуации, когда рассказы сотрудников заведомо ложные, и им нельзя верить. Что можно сделать:
I. Получить нужные административные ресурсы (быть уверенным, что ты имеешь право и возможность лезть в реальные БП и изучать их не со слов сотрудников)
II. Проверить данные в существующих базах и попробовать найти доказательства, что описанный бизнес-процесс не соблюдался
III. Сидеть в отделе и просто наблюдать за работой сотрудников вживую
и т.д. Но вообще такая работа со стороны внешнего IT-подрядчика не особо эффективна, это функции внутреннего аудита. Задача IT-подрядчика — согласовать бизнес-процесс, на который согласен заказчик.
то просто выносить все найденные несоответствия на руководителя функционального блока и коллективно обсуждать их.
Вынести можно то, что уже смоделировано!
Если у нас есть модели всех процессов (и реальных, и целевых, и т.д.) — задача по моделированию решена. Дальше начинается совсем другая сфера функций.
То, что положено по регламенту, тоже моделируется.
Ты приходишь в отдел, наблюдаешь как проходит на самом деле, сравниваешь с регламентом, и либо сразу делаешь замечание, либо моделируешь «как есть».
Только зачем это?
В теории сначала моделируется «как есть», потом проектируется «как должно быть», и после этого под «должно» пишется регламент.
Приходит специально обученный человек, называется «бизнес-аналитик», в отдел, и говорит: расскажите, как вы работаете. Сотрудники рассказывают ему про какой-нибудь свой бизнес-процесс, иногда показывают, аналитик задает уточняющиеся вопросы до тех пор, пока ему не становится понятно. Когда становится понятно, рисует модель бизнес-процесса (например, модель по BPMN).
Так в каждом отделе предприятия, пока все нужные бизнес-процессы не будут описаны в моделях.
Бизнес-аналитик может работать и в штате, и у подрядчика.
По-хорошему, моделирование бизнес-процессов должно быть выполнено до автоматизации, и сами бизнес-процессы не должны меняться во время нее.
Вы же понимаете, что это недопонимание ситуации или подрядчиком, или заказчиком. Если оба понимают функционал системы, «она» в этом треугольнике кого-то подведет вряд ли.
Исключения — неожиданные косяки со стороны вендора (если внедряется новый функционал, который раньше не реверсился участниками проекта, или при обновлениях).
Вот я не понимаю, зачем мне «грузить» разработчика необходимостью писать внутренние (не приемочные) тесты. И разработчики не понимают.
Аргументация «ну попробуй, а если не понравится — попробуй еще много раз до тех пор, пока не понравится» (которая приводится в статье) мне не подходит, поскольку я и так добиваюсь достаточного понимания разработчиками задачи за счет своей постановки и/или, в крайнем случае, написания для них таких тестов самостоятельно. Поэтому хотелось бы, например, увидеть описание сфер, в которых такой подход необходим.
У меня противоположное мнение: разработка на основе тестов может быть способом максимального разделения труда между постановщиком задачи и конечным разработчиком.
Когда разрыв между аналитиком и программистом в понимании сути задачи (и предметной области) настолько большой, что объяснить ее обычным языком достаточно системно становится невозможно, аналитику остается написать набор тестов — формальных ограничений, которым должен соответствовать фрагмент программы.
Когда разработчик пишет тест сам для себя (а в материалах по TDD я иногда вижу именно это) — это напоминает старую добрую «разработку в одно лицо», к которой вместо постановщика задач (аналитика, функционального архитектора) добавляется лишняя бюрократия.
Может быть, конечно, я говорю это из-за того, что я не видел TDD во всей красоте и могуществе.
Я не говорил, что их не нужно описывать. Просто так происходит.
По поводу того, что нет данных, некому их вести или неготовы заполнять — так это и есть положительный результат моделирования — выявленная проблема, в которой обозначена потребность бизнеса и выявлен недостаток ресурсов.
Конечно. Только при модели «Как надо» это нельзя выяснить. Это можно понять, когда понятная разница между тем, как надо, и как есть (другой вопрос, нужно ли и то, и то формально моделировать в нотациях или это можно понять из устных обсуждений — но это понимание обязательно должно быть).
Ну на практике в большинстве случаев компании никакого описания ни реальных, ни целевых процессов не пишут.
Вариант 2 — полностью согласен.
Вариант 1 — теоретически я не против, просто моделирование желаемых процессов в таких случаях постоянно упирается в невозможность их реализовать (оказывается, что часть нужных данных некому вести, их нет или работники не готовы заполнять их на своем этапе, многие действия заранее не смогли предусмотреть или вспомнить при моделировании и т.д.). То есть, такая модель очень сильно отличается от того, что получится в результате. Но, опять же, это может быть специфика тех проектов, с которыми я работал.
Трудно представить себе, чтобы кто-то из владельцев или топ-менеджеров крупного промышленного предприятия приобретал ERP-систему ради моды.
Какая наивная фраза:)
По поводу самого моделирования — мне кажется, нужно моделировать и как есть, и как должно быть, чтобы системному аналитику/консультанту было проще понять гэпы в бизнес-логике.
P.S. Никаких хороших слов не пишу про статью не потому, что я вредина, а только потому, что я не разбираюсь в этой сфере настолько хорошо, чтобы оценивать.
По итогу обсуждения можно будет дополнить статью.
Согласен. Хотя манипуляция не заложена в самом Waterfall, иногда контрагенты манипулируют при его использовании. Как и в любом подходе, в принципе.
Согласен.
Спасибо.
Не понравилась одна эта фраза.
Зачем называть «уловкой» подход, который честно используют в другой методологии.
Если Вам нравится одна методология и не нравится другая — это Ваше дело. Вы можете использовать ее, описывать плюсы и минусы разных подходов, сравнивать их.
Но в этой фразе, на мой взгляд, Вы допускаете манипуляцию.
Это все про расчеты «по кругу», мы про них уже поговорили.
Если Вы считаете, что планирование «сверху вниз» не должно существовать — это отдельная тема для разговора.
Если коротко и без максимализма: разобраться с методикой планирования немного сложнее, чем с учетом. Так?
Да, но это все по сути про рекурсивность расчетов «снизу-вверх/сверху-вниз».
Планируются часто и абсолютные показатели, и относительные.
И вычисления в планах действительно идут и снизу вверх (от детальных к сводным), и сверху вниз (от итоговых к детальных), и по кругу.
Хороший вопрос, который, если получится, я рассмотрю в будущих публикациях. Сейчас в реал-таймовых ERP-системах очень важна информация, которая находится на границе между планом и фактом.
И учет может быть управленческим, и планирование может быть государственным или регламентированным управляющей компанией. Здесь большой разницы нет.
Тем не менее, планы могут ходить «по кругу» между отделами, и отделы могут корректировать только свою часть, не разбираясь в других разделах.
У РП практически никогда нет (и не должно быть) полномочий по построению самих бизнес-процессов.
Я имел ввиду, что он должен принять решение, какие процессы нужно моделировать, если оказывается, что их версий несколько (например, если оказывается, что реальные отличаются от тех, которые рассказывают подразделения). Каждый лишний анализ гэпов увеличивает трудозатраты аналитика, но вопрос «анализировать ли их» не должен стоять перед аналитиком. Ему ставят задачу другие люди (а точнее, руководитель проекта; а с кем он в свою очередь ее согласует, это его дело).
Я в комментариях не делал разницы между «моделировать», «выяснять» и «описывать».
Если Вы об этом — согласен.
Человека, который принимает решение о том, по какой версии бизнес-процессов нужно вести автоматизацию, если этих версий четыре (регламентированные; «как рассказали пользователи»; реальные, о которых никто не знает; те, которые могут получиться с учетом возможностей программного продукта) или больше.
Этот человек — не бизнес-аналитик (не тот, кто описывает эти процессы).
Как описывать — вопрос бизнес-аналитика.
А что описывать — вопрос руководителя проекта.
И ответ на него дается индивидуальный в каждой конкретной ситуации.
Аналитику нужно
1. Получить четкое задание на то, какие именно версии бизнес-процессов нужно смоделировать
2. Допустим, РП ставит задачу выяснить реальные бизнес-процессы, при условии что пользователи их честно не расскажут
3. Теперь аналитик в трудной ситуации, когда рассказы сотрудников заведомо ложные, и им нельзя верить. Что можно сделать:
I. Получить нужные административные ресурсы (быть уверенным, что ты имеешь право и возможность лезть в реальные БП и изучать их не со слов сотрудников)
II. Проверить данные в существующих базах и попробовать найти доказательства, что описанный бизнес-процесс не соблюдался
III. Сидеть в отделе и просто наблюдать за работой сотрудников вживую
и т.д. Но вообще такая работа со стороны внешнего IT-подрядчика не особо эффективна, это функции внутреннего аудита. Задача IT-подрядчика — согласовать бизнес-процесс, на который согласен заказчик.
Вынести можно то, что уже смоделировано!
Если у нас есть модели всех процессов (и реальных, и целевых, и т.д.) — задача по моделированию решена. Дальше начинается совсем другая сфера функций.
Могу научно объяснить, почему это единственный правильный и рабочий вариант, но думаю Вы можете поверить на слово:)
Ты приходишь в отдел, наблюдаешь как проходит на самом деле, сравниваешь с регламентом, и либо сразу делаешь замечание, либо моделируешь «как есть».
Только зачем это?
В теории сначала моделируется «как есть», потом проектируется «как должно быть», и после этого под «должно» пишется регламент.
Так в каждом отделе предприятия, пока все нужные бизнес-процессы не будут описаны в моделях.
Бизнес-аналитик может работать и в штате, и у подрядчика.
По-хорошему, моделирование бизнес-процессов должно быть выполнено до автоматизации, и сами бизнес-процессы не должны меняться во время нее.
Исключения — неожиданные косяки со стороны вендора (если внедряется новый функционал, который раньше не реверсился участниками проекта, или при обновлениях).
Вот я не понимаю, зачем мне «грузить» разработчика необходимостью писать внутренние (не приемочные) тесты. И разработчики не понимают.
Аргументация «ну попробуй, а если не понравится — попробуй еще много раз до тех пор, пока не понравится» (которая приводится в статье) мне не подходит, поскольку я и так добиваюсь достаточного понимания разработчиками задачи за счет своей постановки и/или, в крайнем случае, написания для них таких тестов самостоятельно. Поэтому хотелось бы, например, увидеть описание сфер, в которых такой подход необходим.
Когда разрыв между аналитиком и программистом в понимании сути задачи (и предметной области) настолько большой, что объяснить ее обычным языком достаточно системно становится невозможно, аналитику остается написать набор тестов — формальных ограничений, которым должен соответствовать фрагмент программы.
Когда разработчик пишет тест сам для себя (а в материалах по TDD я иногда вижу именно это) — это напоминает старую добрую «разработку в одно лицо», к которой вместо постановщика задач (аналитика, функционального архитектора) добавляется лишняя бюрократия.
Может быть, конечно, я говорю это из-за того, что я не видел TDD во всей красоте и могуществе.
Конечно. Только при модели «Как надо» это нельзя выяснить. Это можно понять, когда понятная разница между тем, как надо, и как есть (другой вопрос, нужно ли и то, и то формально моделировать в нотациях или это можно понять из устных обсуждений — но это понимание обязательно должно быть).
Вариант 2 — полностью согласен.
Вариант 1 — теоретически я не против, просто моделирование желаемых процессов в таких случаях постоянно упирается в невозможность их реализовать (оказывается, что часть нужных данных некому вести, их нет или работники не готовы заполнять их на своем этапе, многие действия заранее не смогли предусмотреть или вспомнить при моделировании и т.д.). То есть, такая модель очень сильно отличается от того, что получится в результате. Но, опять же, это может быть специфика тех проектов, с которыми я работал.
Какая наивная фраза:)
По поводу самого моделирования — мне кажется, нужно моделировать и как есть, и как должно быть, чтобы системному аналитику/консультанту было проще понять гэпы в бизнес-логике.
P.S. Никаких хороших слов не пишу про статью не потому, что я вредина, а только потому, что я не разбираюсь в этой сфере настолько хорошо, чтобы оценивать.