Вопрос скорее философского толка, поэтому попытаюсь описать максимально общЕ)
Итак: есть некая компания, большая или маленькая - не принципиально. В своей работе она использует некий набор процессов, часть из них реализовано в текущем функционале учетного софта, часть - в excel. Типовая картина. Принимается решение о внедрении нового софта. И стоит вопрос кто же должен описывать текущие процессы.
Вариант 1. Описывают эти процессы, так как они их видят функциональные пользователи, по своим блокам учета. Обоснование: кто же кроме них них это сможет сделать максимально полно и точно? Вариант 2. Описывают процессы консультанты, которые будут внедрять в дальнейшем новый софт. В режиме диалога с теми же самыми функциональными пользователями. Обоснование: кто кроме внедренцев понимает возможности нового софта, и сумеет сделать правильные акценты при описании, не упустить ничего важного и т.д.
Вопрос не в стоимости того или другого варианта, а в эффективности получения максимально полного и точного описания процессов, как исходной информации для дальнейшего внедрения.
Кто что думает? Голосовалку прикручу.

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

(1) Можно и не описывать. Но тогда как найти разницу между as is и to be и определить какие процессы не закрывает внедряемый софт? И принять решение о реорганизации этих процессов или о доработке софта? Делал и так, и так. Но to be только в случае "силового" варианта внедрения, когда клерков просто продавливали со словами "Нам пофиг как вы там работали раньше в своем дерьме - работать будем так!". Далеко не всегда так возможно и далеко не всегда на это есть карт-бланш спонсора проекта.

(3) Пользователи <> Сотрудники

(0) Вопрос наличия вменяемых сотрудников (ИТ а не юзеры) и/или вменяемых наемных консультантов

(4) Есть схема плавного добровольно-принудительного перехода.
Когда обе системы (as is & to be) работают одновременно некоторое время с синхронизацией данных.

И новых пользователей учат сразу в новой системе работать, а старым постепенно режут премию пока не перейдут сами в новую систему/интерфейс.

Но стоит это дороже сильно.

(6) В подавляющем большинстве случаев это невозможно. Чаще с времени Ч начинается работа по-новому.

(7) Угу потому что бюджет

(4) Интересен ваш опыт, если карт-бланш от спонсора проекта на "продавить", то есть ли понимание у спонсора о рисках подобного продавливания. Понятно, что спонсор считает клерков малограмотными туземцами, а себя - конкистадором, но вот видит ли он, чем это может в итоге обернуться? Ибо даже у туземцев есть свои "хинты", без которых в джунглях не выжить.
(6) Т.е. новая система вообще не учитывает потенциальную специфику того предприятия, на которое ее ставят? По умолчанию считается, что новое гарантированно и с запасом покрывает все разумные потребности?

Почему возник вопрос из сабжа: столкнулся с ситуацией, когда меня пытаются убедить, что описание as is должен описать бизнес, а консультанты на основании этого описания должны разработать модель to be. Типа это мировой стандарт внедрения.
Я же полностью солидарен с (3). Описание пользователями системы мне кажется утопией.

(9) Нет, мое замечание не относится к проблеме (0) и as is и to be один фиг надо в этом случае делать и новую систему допиливать до to be а еще плюсом и конвертацию-синхронизацию между c as is ваять что усложняет все от двух раз до порядков.

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

Короче чаще проще (и намного дешевле) поменять кривые бизнес процессы под правильную систему (с правильными процессами) чем криво допиливать ненужное.

Суть в том что люди очень консервативны и если научились деньги зарабатывать через Ж то хрен их перечишь легко.

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

(10) Описывать надо наружные процессы (фирма в целом как черный ящик).
Затем по этому описанию подбираем как должна правильно работать фирма и какие есть готовые системы.

Далее ищем отличие последовательно внутри черного ящика и прикидываем что проще поменять работу фирмы (бизнес процессов) или работу системы/программы

(13)+ Если фирма-контора очень крупная а информатизируем только часть или по частям, то придется "черные ящики" последовательно переставлять. Тут внешние процессы будут в т.ч. внутри фирмы.

(13) Это опять таки утопия. Выбор новой системы, как правило происходит либо пальцем в небо, либо ту, где пресейлы красочнее врут). Либо просто "потому что!", со стороны спонсора.

(15) В этом случая следует просто заплатить, подписать акты, выплатить откат и успокоиться не тратя нервы и деньги на "внедрение".

Ну блин, текущие процессы описывает тот, кто лучше их знает и может объяснить, а реализует, на основании хотелок, внедренец

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

(18) Но если ты траву косишь серпом, то зачем это описывать. Это ты уверен, что данный процесс правильный и косарь Петя с ним справляется. Но, возможно, есть другие инструменты для того, чтобы косить: коса, комбайн, и прочее. И новый софт уже может внутри себя содержать нужные методики, а создавать серп его средствами можно, но зачем?

(10) Нет такого стандарта. Скажу больше - подавляющее большинство внедрюков тоже не умеют описывать бизнес-процессы. За всю жизнь видел только одного действительно сильного бизнес-аналитика, способного это качественно сделать. Потрясающе занудный товарищ, но способный без утюга и паяльника выпытать у пользователей то, чего они сами не знали. Сам от него бегал, ибо если попадешь в лапы, то все. Остальные так, для отмазки какие-то левые схемки рисовали, в которых пробелов больше, чем описания. Боюсь я сам не в состоянии буду это сделать с хорошим качеством в разумный срок - когда постоянно этим не занимаешься, то навыки теряются.

(18) Я уже не говорю о философском, зачем вообще косить траву. Может удобнее будет асфальт. И косить не нужно вообще, а Петя будет вкалывать на другом участке.

(18) Это к описанию процессов каким боком?

(19)Так никто не против комбайнов. Только всему свое время и место. А чтобы это время и место правильно определить, нужно сделать качественное описание, со всеми нюансами и подводными камнями. И как по мне, этим все же должны заниматься специально обученные люди)
Так что проголосую:

(23) Уточни сразу за чей счет

(23) Так вот. Зачем тратить силы на описание того, что выстрелит или нет, нужно-не нужно. Лучше потратить силы на то, чтобы изучить комбайн и внедрить его, а чего сломано, тут уже не нужно понимать и схемы бессмысленны.
Но схемы - хороший способ для отмыва бабла. Ибо тратится столько сил для отображение чего-то в каком-то виде.
Сам рисовал схемы по просьбе дира для одного процесса. Месяца два трудился, описал все нюансы. По факту незначительность нюансов мало кого интрересует и по факту схемы мои использовались как картинка для пример, а можно это описать вот так. Да, красиво, да зрелищно. Это как словесное описание бега. Что такое бег и как он выполняется. Фик разберешь без видео. В схемах так же. Чужой, без знания процесса затыкается сразу. А если знаешь процесс, то нафига схема.

(25) Вы куда-то не в ту степь. Вопрос не в комбайне вообще. Вопрос в процессе. А процесс простой - на входе потребность в скошенной траве, на выходе скошенная трава. Ресурсы - коса, косарь, оселок для заточки и поле. Управление процессом - председатель, выгоняющий пинком на поле, инструкция по пользованию косой и распоряжение о месте покоса. Мы внедряем  процесс кошения комбайном. Остается ли процесс кошения? Да, остается. Меняется что-то в процессе? Да, меняется - нужна инструкция по пользованию комбайном. Ресурсы меняются на комбайн, комбайнера и топливо. Убирается подпроцесс заточки косы и добавляется подпроцесс обслуживания комбайна. Это не вопрос "А не внедрить ли нам комбайн?". Это вопросы:
1. Остаются ли процессы неизменными или меняются?
2. Обеспечивает ли нам новый девайс выполнение процесса или к нему нужно приделать дополнительно жатку?
3. Нужны ли организационные изменения, связанные с изменением процесса и какие?
4. Нет ли необходимости менять смежные процессы или добавлять новые процессы?

(6) Где ты на момент перехода возьмешь х2 пользаков?

Описывают внедренцы, контрольные примеры с рабочей группы

(27) Трех. Третий будет сверять два потока данных, выявлять расхождения, выяснять причины, корректировать при необходимости или держать в голове, что различие обосновано в связи с изменением методики.

(0) А может лучше сначала делать моделирование на новом софте, и в результате приходить к новым процессам?

(30) А что Вы моделировать будете? Позаказный учет с пользованием графика производства на торговом предприятии? Откуда Вы знаете что именно нужно моделировать?

(26) В ту степь. Хотя можно и не в ту.
"Остается ли процесс кошения? Да, остается." Не факт. Если пытаться сохранить этот процесс, как процесс, то да. Если этот процесс кошения - элемент какого-то "эклеселетворчества" и рожден в следствие вбивания какого-то костыля. То описывай его или не описывай - костыль ради костыля... И потребность этот костыль рождает экселопотребную...
Хотя не исключено, что именно процесс описания позволит понять схему в целом. Только вот такие описания очень быстро устаревают, и повторно за их описание уже не хочется.
Если есть в организации библиотекарь для такой описательной деятельности - этакий архитектор, то да он может и описывать процессы и картинки поставлять для презентаций бигбоссов, чтобы они пальцы гнули перед более высоким начальством.

(0) Опыт показывает что описывать должны внедренцы.

Заказчик в большинстве случаев это высокий управленец которому от системы нужен 1-2 отчета в месяц, они решают задачи совсем другого уровня. Остальное их интересует конечно, но мало.
ИМХО специально обученные люди с кейсами должны этим заниматься + возможно все можно еще и оптимизировать в процессе перехода будет.

.

(31) От предпроектного обследования, вестимо.

Все зависит от того, для чего это действо нужно.
Если описание БП предваряет внедрение масштабной ИС на предприятии, то описывает внешний интегратор.
Если вышестоящая организация застала врасплох , то начальники своих подразделений, изобретают свои БП.
Если у службы ИТ, есть предвидение, что будут брать за зебру в скором времени, то приобретается спец ПО, обучаются пара-тройка сотров формализации БП, и те интервьюировают подразделения и через 6-9 месяцев рождают описание БП.

(0) Тут не может быть однозначного ответа.В большом числе случаев заказчик некомпетентен.Искючения из правила тоже бывают.
Поэтому

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

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

Если деньги есть - наймите специализирующуюся на этом консалтинговую контору из big four. Они и опишут, и рекомендации методологические дадут.

(0) при автоматизации процессы могут меняться. А иногда просто обязаны меняться.
Раньше Вася писал письмо, Маша относила письмо на почту, Таня письмо с почты забирала, а Коля содержимое письма обрабатывал. Завели электронную почту, и процесс изменился: теперь почту никто не носит и не забирает.

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

(41) Не верю я в Реинжиниринг, вот в инжиниринг верю

(0) >>Описывают эти процессы, так как они их видят функциональные пользователи, по своим блокам учета.

Пользователи описывают свои влажные фантазии, это проверено на практике неоднократно.
Описывать должны специалисты по внедрению и стоимость этого описания закладывается в проект автоматизации. Далее эти процессы анализируются и описывается чем и как они будут заменены. Если такого описания не делать, то это вызывает негативную реакцию со стороны пользователей (вплоть до саботажа), что затрудняет процесс внедрения.
Можно конечно ничего не описывать, но это будет силовой вариант внедрения. Если руководство готово к силовому варианту, вплоть до массовых увольнений, то такой вариант тоже имеет право на жизнь. Иногда силовые варианты даже приносят неплохие результаты, но это в том случае, если заказчик точно знает чего он хочет и готов к применению силы.

Частично согласен с комментарием Волшебника в (1) - бывают случаи, когда можно сразу делать "как будет", без описания "как есть".
А в универсальном случае описывать нужно внедренцам, чтобы понимать "внутреннюю кухню". В существующих БП может быть рациональное зерно, надо его сохранить и преумножить.

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

Описывать роцессы должен независимый эксперт по бизнес-процессам. Лучше когда к 1С эксперт относится никак

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

Т.к. ответ очевиден и оторван от реальности, а соответственно вопрос бессмыслен, то

(46) >Лучше когда к 1С эксперт относится никак

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

(3) Золотые слова. Даже добавить особо нечего.

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

(51) Ересь,
Исполнитель должен сделать презентацию отражения текущих БП
И может Предложить оптимизацию если есть такой скил

(51) Как правило, все текущие под ИС подогнать не получится в полном объёме ¯\_(ツ)_/¯
Тогда-то и нужен БА, знающий реализацию БП в ИС, чтобы подогнать текущие к ИС по максимуму.

(24) > Уточни сразу за чей счет

Странный вопрос. Любую работу внедренцев оплачивает заказчик. Даже если за эту работу ему не выставляли счета.

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

(43) >>если заказчик точно знает чего он хочет

А такие бывают? Обычно понимание "чего действительно нужно" приходит уже во время эксплуатации, после набитых шишек

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

(57) Знакомая рассказывала. В РЖД внедряли САП. Пришли какие-то спецы, собрали пожелания, описали рабочие места.
Внедрили! ВУАЛЯ! Былой софт отрезали. Стояла раньше 1С. Подключили новый. В новом софте даже при выборов пунктов меню выскакивали ошибки. Глянули свои рабочие места, из того, что им нужно по функционалу и половины нет. Как работать. Обратились к начальству. Начи сказали, что внедрение закончилось, кому что не нравится - увольняйтесь.

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

(58) Сап да, он такой. Бессмысленный и беспощадный)

(57) Еще раз - это совершенно бесполезное и бессмысленное действие. Если какие-то идиоты, начинавшиеся умных книжек, это делают, то это не означает, что само действие становится осмысленным. И чем "нормальнее" тендеры, тем больше там идиотизма, т.к. большая часть причастных работает "на бумажку", а не на результат. Особенно доставляет "А вот мы опишем процессы и выберем наиболее подходящий нам продукт". Не работает нигде и никогда, но все упорно бьются головой о стену. Сферическое в вакууме описание никому не нужно. Оно всегда должно писать под определенную цель. Потому что в зависимости от цели процессы ранжируются по приоритетам и определяется круг описываемых процессов. Если мы не собираемся автоматизировать процесс мытья полов, то его описание на фиг не нужно. Если мы собираемся, даже не автоматизируя, оптимизировать процесс мыться полов, регламентировать его, выстроить систему KPI, организовать контроль качества - нам нужно его описывать. Т.е. "ширину" и "глубину" описания мы выбираем в зависимости от конкретной задачи.

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

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

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

(64) ну так при подобном факапе Исполнитель типа не причем. Деньги получены, ничего не работает, виноват Заказчик. Идеальная тема

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

(64) А вот это абсолютно истинное утверждение.

(65) исполнителю тоже хочется проект в портфолио положить, а не только деньги

(66) Могут и не стыковаться. значит эзиз такой. у пользователя должен не только говорить и но и показывать на 1с, в ексель - где и чего он делает. и все равно 100% точность с первой итерации не получишь

(58) тем не менее внедрили. В РЖД SAP, по крайней мере, хорошо выполняет функцию ЗУПа и Бухии.
Кстати, работал с одним бывшим начальником ИВЦ железной дороги. Там такой дедушка боевой был, - сегодня он пойдёт к большому начальнику и подпишет приказ о внедрении чего-либо, а на завтра у него все территориально-разбросанные подразделения уже будут через пот и слёзы колотить данные в свежеразвернутой системе. Возможно, в больших структурах только так и можно внедрять сложные системы: административными пинками, через колено заламывая непокорных. Попробуй устроить демократию, и тут же внедрение начнет саботироваться, вставать колом.

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

(71) Во всех этих замечательных пожеланиях о том кто должен что описывать - не учтена динамика бизнес-процессов.

Пока внедренцы описывали БП для ЕРП 2.1  - внезапно случился 54-ФЗ, 1С сменила версию 2.1 на 2.2 сняв 2.1 с поддержки. В вместо ЕГАИС 1 пришел ЕГАИС 2.

Бюджетов и ресурсов на переход с 2.1  на 2.2 предусмотрено не было. Впрочем это был не самый эпик фейл - но вполне показательный.

(71) в регламент вообще смотреть не нужно

(72) а да

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

Если заказчик умеет описывать бизнес-процессы настолько - что на основании них можно внедрять ПО уровня ЕРП - внедренцы ему не нужны.

(72) да, с 2.1 на 2.2 был жестокий переход

(72) Замечательное уточнение! Модель бизнес-процессов нужно постоянно поддерживать в актуальном состоянии. Если упустить это, то предприятие будет жить своей жизнью, а модель своей.

(72) Это частности отдельно взятых процессов вообще-то.
Если завтра ФНО изменится, нужно ли по новой описывать БП сдачи налоговой отчётности, прям вот с нуля?

+(77) Который, в свою очередь, один из второстепенных относительно ключевых БП, подлежащих автоматизации.

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

(76) Согласен, но всё-таки на время внедрения эту модель лучше замораживать. Упомянутые моменты с ЕГАИС - чисто техническая заморочка, а не изменение БП.

НО есть огромное "НО" :

Исполнитель любого уровня не знает цели своей работы.

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

(81) as is не описывает "зачем", только как есть

(82) Так вот исполнители как раз и не знают что они делают. Они бьют и печатают документы. Толку от этих знаний 0.

(83) зато это реальный as is, а не то как это видит начальник

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

(84) Это не as-is, это попытка рыбы описать аквариум.

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

(85) А как вы предполагаете подходить к описанию БП as is?

(85)(86) Вот его начальник и прекрасно опишет какие воздействия он посылает, какие ожидает, а какие получает. А исполнителя можно опросить только насчет деталей его работы чтобы доработать напильником.

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

(88) а потом выясняется что они между собой мимо начальника о чем то договариваются

(88) Хорошо если один линейный руководитель на группу из трёх-четырёх сотрудников, занимающихся одним и тем же.
А если это ГБ со штатом из 15 тёток в подчинении, закреплённых каждая за своим участком?
ГБ сможет детально описать все процессы своего подразделения?

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

конечно сначала нужно с начальником поговорить, чтобы вообще очертить какие участки есть, а сами участи уже на местах

тут даже язык не поворачивается выбрать "вариант 1".

А зачем делать описание as is? я так понимаю, оно нужно, если внедряемая система будет подстраиваться и переписываться под текущие процессы (которые более менее нормально работают). Если их планируется ломать, то описывать существующие процессы нет смысла.

(95) а как же понять нужно ломать или допиливать?

(95) А как определить ту "дельту", на которую нужно изменить что-то? Только путем сравнения того что есть с тем, что будет. И выявив отличия, уже "ломать".

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

(98) а бюджет как ты оценишь тогда?

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

(98) А если внедряемый софт не перекрывает имеющийся процесс и допиливать нужно? Ну и действительно для оргизменений.

(101) ну так я и говорю, что если существующие процессы берутся за основу, тогда нужны схемы as is. Иначе от них проку мало.
Например, на заводе в производстве бардак, все тырят металл/комплектующие друг у друга. Ну и толку что такую схему отрисуют? В любом случае ее не автоматизировать, и брать за основу наверно не следует (если руководство адекватное).