cyxВ вакансиях аналитиков часто пробегает следующая строчка:
Проведение работ по анализу требований:as is/to be
Вопрос: в какой форме принято представлять заказчику результаты подобных работ, имеют ли они для заказчика (предприятия) самостоятельную ценность, какие инстр. средства используются? Может быть есть более содержательные синонимы?

asis/tobe ... по отношению к требованиям, несколько непонятно что имеется ввиду ... ну если только есть старое ТЗ, есть поток изменений и нужно сделать обновленное ТЗ :-).

UrriВсе просто.
As is - это результат исследования бизнес процесса в том виде, как он реализован сейчас.
To be - это то, как он должен быть реализован в результате внедрения некоего изменения.
К программному обеспечению, следовательно и к ТЗ, и то, и другое имеет весьма условное отношение. В конце концов, есть бизнес процессы, которые никак не автоматизированы. Это не значит, что они не могут изменяться.
Инструмент часто - Visio, где изображаются диаграммы workflow.

Какое отношение модели БИЗНЕС-ПРОЦЕССОВ имеют к ТРЕБОВАНИЯМ к ПО (в вопросе фигурировал термин "требования")? ... это разные области знаний. В SWEBOK в частности определено что относится к области знаний "Программные требования" (см. перевод SWEBOK в блоге Сергея Орлика). "Радует" меня микс в головах ... "все смешалось ... люди, кони" :-)

UrriНу привет! Что автоматизируем-то? Бизнес автоматизируем.
Впрочем, может быть, я не прав, и кому-то приходится анализировать требования к ПО в отрыве от автоматизируемых процессов. Дело в том, что я сам - бизнес аналитик и имею дело с бизнес ПО, поэтому для меня любой автоматизируемый процесс - это бизнес процесс.

Вопрос на засыпку :) Чем бизнес-аналитик отличается от системного аналитика и постановщика задач? :-) .... Право, мне интересно будет услышать ответ.

Очевидно, если речь идет об автоматизации деятельности организации в части каких-нибудь бизнес-процессов, то чтобы понять как устроен бизнес возможно имеет смысл описать БП в каком-либо виде. Так же очевидно, что не всегда автоматизируется бизнес-процесс целиком, а ряд операций может выполняться вручную. Требования к ПО будут описывать именно требования, эти требования вполне могут быть оттрассированы на определенные бизнес-процессы. И речь не идет об формировании требований к ПО вне контекста автоматизируемых БП, если вы об этом. Сами по себе описания бизнес-процессов не всегда достаточны для разработки ПО, сильно зависит от того:
а) что именно вы называете бизнес-процессом (иногда процессы которые происходят "внутри системы" -- как то сохранение записи в БД, изменение "флагов" бизнес-сущностей и т.п., что в том же AIM отсносится к "фунцкиональной архитектуре")
б) с какой степенью детализации вы описываете БП
в) включаете ли вы в понятие БП собственно информационную систему (как это ненавязчиво делают консультанты по ERP).
Кроме этого, существует вполне формальное определение что есть требования к ПО и это увы не бизнес-процессы, у которых, в свою очередь так же есть определение -- что есть БП .... так что отличие, как говорится, по-определению.

Кроме этого собственно вопрос по автоматизации бизнес-процессов и моделям AS-IS и ТO-BE. Представим себе ситуацию - вы копали большой котлован силами 30 человек используя лопаты. Потом решили автоматизировать свой процесс копания котлована -- стали использовать экскаватор. Ваш бизнес-процесс и его конечный результат изменился? Или просто вы стали копать котлованы быстрее и (возможно) дешевле? И как будут выглядеть модели asis-tobe при этом?

shelsoft iv250973
1) Любой аналитик при слове классик вспоминает основоположника тов. Карла Вигерса
2) Любая методика родившаяся вне определенного территориального пространства должна быть адаптирована к условиям сформировавшим на нашей почве определенные национальные правила для описания текущих бизнес-процессов. Потому как явный перенос приводит к трансформации условно говоря эллиптических моделей к явно ортогональным.
3) Батенька не шаманьте ), в противном случае вы можете оказаться в положении конферансье Театра Варьете Жоржа Бенгальского


^{______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным}


Трава видать забористая .... :-).

shelsoft byur
Не кажется ли Вам что что-то оторвалось в Вашем деле от реального мира и перешло на уровень метафор и заклинаний (меня заставила об этом подумать тематика, содержание докладов и реакция публики на SWEBOK & etc. Для себя я извлек конечно практический результат, но тема подается с таким же пафосом как Макдональдс торгует своими явно не котлетами)


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

WJ byurВопрос на засыпку :) Чем бизнес-аналитик отличается от системного аналитика и постановщика задач? :-) ....Бизнес-аналитик анализирует состояние, развитие, потребности и возможности бизнеса. Независимо от того, насколько он (бизнес) автоматизирован. Бизнес-аналитик теоретически может обходиться без автоматизации (это как бухгалтер - у него есть специальное ПО, но вообще-то он и на абаке может баланс посчитать, если он настоящий бухгалтер, а не просто "опытный пользователь ПК").
Системный аналитик анализирует системные ресурсы, их использование, возможности и т.д. И, исходя из требований бизнеса (можно сказать - бизнес-аналитика) и результатов анализа "ставит диагноз" - какие ресурсы и как и куда и т.д....
Постановщик задач - это лицо "без определенного места жительства". По-сути - заказчик. Исходя из того, что глобальным заказчиком является бизнес, то постановщик имеет все же статус "бизнес". Хотя в постановке задачи скорее всего должна участвовать группа людей, представляющих обе стороны.
Не думаю, что это новость для вас:)

+1 :-)

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


... Предчувствуя последующие упреки в "придирке к словам", и "ну вы же понли что я имел ввиду" и т.п. тем не менее скажу -- все начинается с путаницы в определениях :-). Под приведенное определение попадают ВООБЩЕ все процессы :-), даже быстротекущие в ядерных реакторах :-). Но это так, к вопросу об определениях.

Urri
Процессы, происходящие внутри системы, также могут рассматриваться как этапы бизнес процесса. Например, программа, запускаемая по расписанию, выполняет некоторое действие, важное для бизнес процесса и рассматривающееся как его отдельный этап, хотя его вроде бы никто не инициирует (иногда выгодно абстрагироваться от того, что сначала кто-то эту программу когда-то должен был поставить на расписание). Но это все-таки чаще более высокий уровень абстракции, нежели "сохранение записи в БД" или "изменение "флагов бизнес-сущностей". Впрочем, иной раз и этим оперируем. Например, действие "сохранить документ, содержащий следующий набор атрибутов: ........., в системе" может быть выделено как этап БП. Или: документ был в статусе "не утверждено", а после этапа утверждения должен стать "утверждено" или "отклонено". Это ведь как раз изменение флага, не так ли? Просто в таблице системы этот атрибут может называться APPROVED_FLAG и иметь значения Null/'Y'/'N'. Но бизнес об этих тонкостях знать не обязан. Однако решение утверждающего - это этап БП.


Т.е., как я понял из вашего ответа -- имеем по сути некую кашу -- без явного понимания того, что является автоматизированной системой (вспомним ГОСТ 34, а там дано хорошее определение :-)), и как оценить эффективность этого самого процесса. Это и есть best practice?

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


Т.е. получаем фрагментарную документацию? Без явного понимания уровней детализации?

Urri
в) Грешен, включаю ;-). Мой конечный результат - реализация некоторого изменения - как правило, связан с доработкой ERP-системы, в силу области деятельности. Поскольку весьма немалый ряд шагов, ранее автоматизированных с ее помощью, иногда целесообразно описывать так: "Запуск отчета 125", а не выпендриваться с расписыванием, для чего это, собственно, надо (это и так всем, кому нужно изменение, известно).
Встречный вопрос. Вам что в итоге нужно, безупречную документацию получить или реализовать изменение максимально эффективно? И как эффективно: в краткосрочном или долгосрочном плане? С точки зрения бизнеса не все так однозначно. Кстати (может, я сейчас крамольную мысль выскажу ;-)), если проектную документацию готовить целиком по AIM-у, то ни на что, кроме документации, в итоге средств не останется! А ведь у каждого проекта есть требуемая цель и ограниченное количество ресурсов для ее достижения. И документация сверх необходимого минимума, как правило, является лишь побочной целью.


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

UrriПо поводу котлована. Результат - нет. Процесс - безусловно.

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

DinamoХотел бы предложить свое понимание данного вопроса.
Ключевое слово в названии профессии - бизнес .
Бизнес-аналитик это специалист который помогает компании развивать бизнес-направления, основные и вспомогательные бизнес-процессы в соответствии со стратегическими целями. Бизнес-аналитик по сути является - "инженером".
.....

+1

shelsoft
1) Не из-за них, путаница из за тех кто свято верит что теория и есть практика. В бытность прочитав ваш доклад в ВТБ24 в этом убедился.


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

shelsoft
2) Найдите мне практический пример "внятной технической документации" для отечественного специалиста-эксплуатационщика UML фактически полезную диаграмму примененную им. ИХМО все это необходимо (и обязательно) для тренировки мозгов разработчика ПО вышедшего минимум за уровень Senior. Ну а с точки зрения семинаров магический язык западных методик бездумно перенесенных на нашу почву становится опознавательным знаком для узнавания таких же посвященных или гипнотической лекцией для сотрудников госкоорпораций.
3) Мне гораздо ближе позиция AlexTheRaven как практика в отличии от экспертов "людей которые которые не думают, а знают"


1. Если вы чего-то НЕ ВИДЕЛИ ЛИЧНО, это не означает что этого не существует. Мне довелось видеть "внятную документацию", и я даже проводил assesment на одном из ведущих авиапредприятий на просторах России, единственном выжившем в смутные времена и ныне очень успешном. Причем делали с использованием UML. Самое интересное, что они фактически самостоятельно поставили себе процесс на базе RUP. Потребовались только незначительные корректировки, чтобы процесс был эффективен + поддержка его инструментарием. Более того, у них есть служба внутреннего ИТ аудита, и более того, они ПОНИМАЮТ, что это им дает. Есть и другие примеры, например на АСУТП в энергетике -- тоже лично видел. Не идеальная, но good enough. Самостоятельно оценивать документацию которую делал сам (в частности работал с юзкейсами, описывал процессы причем часто на UML ...) считаю нескромным. Но, смею вас заверить что как правило на мои документы приходит очень мало замечаний. Кстати, в том же ВТБ был случай, на один мой документ товарищ который очень сильно сопротивлялся изменениям процессов прислал замечания в виде четырех пропущенных запятых :-), каюсь грешен.
2. Разница между моей позицией и вашей (в том выражении, в котором вы ее описали) в том, что вы апеллируете ТОЛЬКО к некоему практическому опыту. А я опираюсь в своей практической деятельности на определенные теоретические знания, к коим отношусь с уважением и которые, несомненно, приходится творчески применять в конкретных проектах, не только консалтинговых. Моя точка зрения, что для того чтобы понять применим ли определенный метод в данных условиях следует как минимум знать суть этого метода, и очень желательно попробовать его применить. После чего провести анализ и на основании анализа делать обоснованные выводы. Иначе относиться серьезно к заявлениям об "особенностях российского менталитета", "самобытности" не следует. Это не означает что особенностей нет, встречаются, но на то и вы вооружены знаниями... К сожалению, мне чаще приходится сталкиваться с тем (например была одна дискуссия с приверженцами ГОСТа в свое время) что о зарубежных методологиях и стандартах рассуждают по принципу "Солженицина я не читал, но осуждаю" :-). Да, бывают случаи, когда читали, попробовали, не пошло ... был один пример у меня такой с применением тех же юзкейсов в одной небольшой софтверной компании -- попросил посмотреть их юзкейсы и все стало понятно ... люди взяли лиш "форму", но не суть. От этого и проблема.

shelsoft byur1) 2)
1) Виноват - ВТБ. Процесс там "до сих пор работает". Ну и что процесс кредитования юридических лиц в автоматизации разработки которого я имел честь принимать участие работает уже больше 20 лет, впрочем с незначительными изменениями произошедшими с 1422 года (что удалось отследить согласно имеемым на тот момент историческим публикациям о деятельности ганзейских банков ))


Ну это ж две разницы! Мне довелось проектировать как сам процесс, так и его автоматизацию. Вы занимались только автоматизацией существующего несколько веков процесса, который за это время успел стабилизироваться :-)))))