Первая часть статьи «Разработка технического задания «Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» вызвала немалый интерес. Кроме своей рассылки, я ее опубликовал и на известном сайте разработчиков Инфостарт, где она вызвала еще больший интерес, что не может не радовать. Как и обещал, пишу продолжение.
Хорошо подумав, я решил, что вместить весь материал планируемой второй части в одну статью опять не получится, иначе это будет верхами и в теории, что и так написано во многих учебниках. Но ведь я ставлю задачу, чтобы это можно было применять на практике, поэтому не буду больше загадывать на будущее о том, сколько выпусков еще потребуется, чтобы закончить с темой. На это будет влиять и обратная связь с читателями, так что пишите, не стесняйтесь!
Пользуясь случаем, хочу задать вопрос: на сколько интересна была бы организация практического семинара-тренинга в Санкт-Петербурге на тему разработки Технического задания? Встретились бы, опытом обменялись. Если такой интерес будет не единичным, обещаю организовать.
Поскольку читателями являются не только специалисты в области разработки программного обеспечения, а также бизнес-аналитики и руководители различного уровня, постараюсь писать так, чтобы было интересно всем.
В этой части мы будет говорить о том, как организовать этап работ по сбору требований, из чего он должен состоять и какими инструментами можно пользоваться. Повторюсь, что данные работы с точки зрения этапов очень похожи на обследование предприятия с целью описания бизнес-процессов.
Как обычно происходит в жизни:
| Как это происходит в большинстве проектов | |
| Шаги | Как это происходит |
| Решение принято, проекту быть! | Понятное дело, что есть повод для радости, особенно, если проект большой, ничего плохого в этом нет! Главное, не радоваться слишком долго, оттягивая начало фактических работ, с этой минуты время будет идти по-другому. |
| Провели совещание с руководителями, собрали некоторую информацию об их видении результата. | Обычно этот процесс ограничивается несколькими встречами с руководством, затем с руководителями подразделений. Зафиксировав некие «позывы» со стороны Заказчика, они фиксируются в виде общих формулировок. Иногда к этому добавляют имеющуюся документацию (кто-то когда-то пытался уже поводить обследование, документы по существующим регламентам, формы используемых отчетов) Как ни удивительно, но после этого большинство внедренцев систем автоматизации радостно восклицает: «да в нашей системе все это есть! Ну немного поднастроить и все будет работать». На вопрос, надо ли обсуждать, как все должно работать (или как выполняется конкретный процесс) с конечными пользователями, ответ обычно отрицательный. Высказывается мнение, что руководитель все знает за своих подчиненных. А зря… За этим скрывается множество ловушек и препятствий, и сдача работ может превратиться в марафон по полосе с препятствиями. Как известно, марафон принято бегать по ровной дороге, а бег с препятствиями возможен только на коротких дистанциях (можно и не добежать). |
| Документирование результатов работы | После этого начинается документирование результатов в зависимости от целей работ: Если требуется разработать Техническое задание, консультант начинает рассовывать полученную информацию по заготовленному шаблону документа, чтобы и выглядело красиво, и основные требования были зафиксированы (те, что озвучены от руководства, а то ведь могут не утвердить). Понимая, что на практике такое Техническое задание особо не используется и приходится все выяснять «по ходу дела», главной целью Технического задания он ставит минимальное время согласования и утверждения. И, если получится, информация для примерной оценки стоимости будущих работ (кстати, тоже немаловажно). Если требуется описать бизнес-процессы. Как ни странно, но часто все предшествующие действия выглядят аналогично, как и в случае с разработкой Технического задания. Разница лишь в оформлении документации. Тут возможны варианты: консультанты описывают процесс произвольными словами или используют какие-либо правила описания бизнес-процессов (нотации). В первом случае такой документ получается удивительным образом похож на Техническое задание. Бывает даже такое, что если заменить титульный лист, никакой разницы не увидишь.В последнем случае часто делают акцент не на соответствии действительности, а на «правильности описания», т.е. формальное следование правилам описания.К сожалению, оба варианта являются не самой лучшей практикой, т.к. являются скорее формальностью, а пользы приносят не много. |
Почему сложилась такая практика, как описано выше? Признаться, я не знаю. У кого ни спроси, никто не знает. При этом ситуация меняется не очень быстро, хотя на эту тему постоянно дискутируют, обмениваются опытом, пишут книги… Мне кажется, что одна из причин – низкое качество соответствующего образования. Может еще сказывается и тот факт, что много специалистов приходит вообще их другого бизнеса, и постигают все на практике, т.е. их опыт формируется в той среде, куда они попали. Об отношении ВУЗов и отсутствия их стремления быть ближе к реальности, тоже факт известный, но меня иногда удивляет их позиция. Например, у меня был случай, когда дипломница, талантливый специалист, хотела писать дипломную работу на платформе 1С (хорошую отраслевую разработку), но на кафедре ей сказали, что независимо от темы, на оценку «отлично» рассчитывать будет нельзя, т.к. 1С несерьезная система. Тут дело не в серьезности и объективности такого мнения, а в том, что примитивное задание на классическом языке программирования тут же считалось достойным оценки «отлично».
Давайте попробуем придать рассмотренному выше процессу более системный подход. Как он может тогда выглядеть?
Как видим, процесс заканчивается вопросом, т.к. на этом работа далеко не закончена и дальше начнется самое сложное и самое практичное – именно то, что будет определять применимость полученного результата в реальной жизни. Именно то, что будет определять судьбу предыдущей работы: или она отправится в шкаф (на полку или еще куда-нибудь), либо будет представлять собой ценный источник информации. А еще лучше, если она станет образцом для последующих проектов.
Хочу особо отметить, что до последнего шага на схеме (там, где вопрос) общий принцип сбора информации о деятельности компании выглядит одинаково, независимо от того, что планируется делать в дальнейшем, описывать бизнес-процессы или внедрять автоматизированную систему. Да, сама последовательность шагов одинаковая, но инструменты, применяемые на некоторых из них, могут отличаться. Мы данный момент обязательно рассмотрим, когда будем изучать методики и инструменты отдельных этапов. Подробно будем это делать в отдельных статьях, а сейчас рассмотрим только самое главное. Дальнейшие шаги будут отличаться и определяться тем, что требуется от проекта: описать бизнес-процессы или внедрять систему учета.
- В первую очередь тем, как Вы обучили проектную группу Заказчика. Они должны четко понимать, как происходит процесс анкетирования и уметь донести информацию до всех участников
- Сама форма анкет. Анкеты должны быть понятными. Желательно, чтобы была инструкция по заполнению анкет. Еще лучше, если будет пример заполнения.
- Состав участников. Необходимо правильно выбрать состав участников. Если ограничиться только руководителями, собрать достоверную информацию не получится. Я рекомендую включать в состав анкетирования всех, кто будет в будущем являться пользователем конечных результатов. Например, если речь идет о внедрении автоматизированной системы, то стоит включить всех, кто будет являться пользователем. Бывают случаи, когда из 10 сотрудников одной должности найдется один, который выполняет какую-нибудь особенную функцию, о которой никто из оставшихся 9-ти больше не знает (например, готовит особый отчет для руководства). Если речь идет о дальнейшем перераспределении обязанностей или разработке должностных инструкций, следует поступить аналогично.
Вот и добрались до вопроса «Что дальше?». Дальше будем рассматривать задачи описания бизнес-процессов и разработки Технического задания отдельно. Я не случайно рассматриваю эти задачи параллельно. Между ними действительно много общего, что я и хочу продемонстрировать. Сначала рассмотрим последовательность работ при описании бизнес-процессов.
| Шаги | Что и как делать |
| Выделяем бизнес-процесс | Из общего перечня бизнес-процессов, полученного на предыдущих этапах, выделяем один (по приоритету) для детальной проработки. С остальными затем поступаем аналогично. |
| Детальное изучение бизнес- процесса | Выделенный бизнес-процесс подвергаем детальному изучению: анализируем полученные первичные документы, отчеты и их структуру, используемые в процессе программы, различные файлы (например, Excel), разговариваем с конечными исполнителями. Собираем различные идеи о том, как можно улучшить процесс. Очень полезно, если удастся понаблюдать за процессом именно в тех условиях, в которых он выполняется (не многие любят, когда за ними наблюдают, но что делать) |
| Графическое и/или текстовое описание бизнес-процесса (первичное) | Полученную подробную информацию начинаем описывать.Прежде чем описывать процесс, надо определиться, потребует ли он графического описания. Если процесс простой и понятный, функций в нем мало, и, графическое представление не улучшит его понимание или восприятие, то не надо тратить на это время. В этом случае достаточно описать его в текстовом виде в табличной форме. Если же процесс сложный, с различными логическими условиями, то лучше привести его графическую схему. Диаграммы всегда воспринимаются легче. Если Вы решили описать процесс в графическом виде, это вовсе не означает, что не надо приводить его текстовое описание. Т.е. текстовое описание процесса должно быть в любом случае, причем выполненное по одинаковой схеме. Удобно это делать в виде таблицы, в которой указать: исполнителей каждого шага, какую информацию они получают на входе, описание каждого шага, какую информацию формируют на выходе. Ниже мы посмотрим на примере, как это может выглядеть. |
| Согласование с исполнителями и владельцем бизнес-процесса | Лучший способ понять, насколько удачно вы выбрали стиль изложения информации, это показать результат пользователям (исполнителям) процесса.На самое главное в такой демонстрации это понимание того, насколько правильно Вы поняли, как процесс выполняется.Если обучение проектной команды прошло успешно, то можно ожидать от исполнителей вполне адекватной обратной связи. А если им станет интересно, то продвигаться все начнет гораздо быстрее.Выявленные уточнения и несоответствия необходимо отразить в описании (актуализировать), при необходимости операцию повторить. |
| Выделение показателей бизнес-процесса | После того, как выработано правильное понимание, как выполняется бизнес-процесс, надо подумать над показателями, которыми можно измерить качество или скорость выполнения процесса. Это не просто, но необходимо. Показатель должен быть измеряемым, т.е. выражен в числовом выражении и должен существовать простой способ эту величину получить. Если измеряемый показатель выделить невозможно, есть риск того, что бизнес-процесс выделен неудачно. Кроме того, не будет возможности понять (измерить ведь нельзя), приведут ли изменения процесса к его улучшению или нет. |
| Окончательное документирование бизнес-процесса | После того, как мы убедились в правильном понимании, как процесс выполняется (или должен выполняться), можно включать его в документацию. |
| Дальнейшие действия (или их отсутствие), в зависимости от целей проекта | Дальше возможны варианты: рассматриваемые процессы будут анализироваться и оптимизироваться, разрабатываться должностные инструкции, приниматься решения о необходимости автоматизации отдельных процессов и т.д.Это может быть и отдельный проект: описание бизнес-процессов. |
Теперь рассмотрим, как будет выглядеть подход к изучению требований к информационной системе с дальнейшим их отражением в Техническом задании
- А что, если планируется разработка новой системы и моделировать попросту не в чем?
- Что, если для демонстрации не хватает функциональности, и систему надо дорабатывать?
Если внедряется готовая система, и в ней не хватает функциональности, то ничего страшного нет, данные вносятся руками, а пользователю так и рассказывается, что после необходимых доработок должно рассчитаться так-то и так (и он это видит).
Да, разработка Технического задания процесс трудоемкий, а значит и затратный. Но если он сделан грамотно, то избавляет Заказчика от не сбывшихся ожиданий. Исполнителю приходится делать то, что требуется Заказчику и не переделывать сто раз одно и тоже. Да и вообще, придает всему проекту прозрачность.
Источник: habr.com
Введение. Типовые задачи описания бизнес-процессов
а ранних этапах проектов, целью которых является реорганизация бизнес-процессов и внедрение информационных систем, у руководителей и специалистов наиболее часто возникают следующие вопросы:
1. каких результатов с точки зрения улучшения деятельности организации можно добиться, используя технологииописания и реорганизации бизнес-процессов;
2. какое программное обеспечение использовать в проекте («ARIS лучше BPwin?», «ERwin лучше ARIS?» и т.п.);
3. как моделировать процессы с использованием продукта «Х»;
4. как проводить анализ и выявлять проблемы при помощи продукта «Х»;
5. какую методологию использовать для описания процессов;
6. что делать дальше с полученными моделями бизнес-процессов.
В настоящее время на российском рынке представлено достаточно большое количество CASE-систем, многие из которых позволяют так или иначе создавать описания (модели) бизнес-процессов предприятий. В то же время существуют системы, ориентированные в первую очередь на создание моделей процессов и неудобные или вообще не предназначенные для создания моделей данных и настройки СУБД. Очевидно, что выбор системы определяется целями проекта и в значительной мере влияет на весь его дальнейший ход. Рациональный выбор системы возможен при понимании руководством компании и ее специалистами нескольких аспектов:
1. целей проекта;
2. требований к информации, характеризующей бизнес-процессы и необходимой для анализа и принятия решений врамках конкретного проекта;
3. возможностей CASE-систем по описанию процессов с учетом требований п. 2;
4. особенностей разрабатываемой/внедряемой информационной системы.
Говорить о преимуществе той или иной системы/нотации бессмысленно, пока не определены тип и рамки проекта, а также основные задачи, которые данный проект должен решить. В нашей статье сделана попытка провести сравнение наиболее популярных нотаций (систем обозначений, принятых при моделировании), используемых для описания бизнес-процессов, и двух систем, поддерживающих эти нотации. Предполагается, что этот материал послужит основанием для дискуссии, посвященной проблемам эффективного применения CASE-систем для описания и анализа бизнес-процессов предприятий.
Описание бизнес-процессов проводится с целью их дальнейшего анализа и реорганизации. Целью реорганизации может быть внедрение информационной системы, сокращение затрат на выпуск продукции, повышение качества обслуживания клиентов, создание должностных и рабочих инструкций при внедрении стандартов ISO 9000 и т.д. Для каждой такой задачи существуют определенные параметры, определяющие набор критических знаний по бизнес-процессу. От задачи к задаче требования к описанию бизнес-процессов могут меняться. В общем случае модель бизнес-процесса должна давать ответы на следующие вопросы:
1. какие процедуры (функции, работы) необходимо выполнить для получения заданного конечного результата;
2. в какой последовательности выполняются эти процедуры;
3. какие механизмы контроля и управления существуют в рамках рассматриваемого бизнес-процесса;
4. роли и ответственности — кто выполняет процедуры процесса;
5. какие входящие документы/информацию использует каждая процедура процесса;
6. какие исходящие документы/информацию генерирует процедура процесса;
7. какие ресурсы необходимы для выполнения каждой процедуры процесса;
8. какие документация/условия регламентируют выполнение процедуры;
9. какие параметры характеризуют выполнение процедур и процесса в целом;
10. существует ли последовательность процессов, минимизирующая затраты (в том числе стоимость, время и т.д.);
11. насколько процесс поддерживается/будет поддерживаться информационной системой.
Описание бизнес-процесса формируется при помощи нотации и инструментальной среды, позволяющих отразить все указанные выше аспекты. Только в этом случае модель бизнес-процесса окажется полезной для предприятия, так как ее можно будет подвергнуть анализу и реорганизации.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Цели описания процессов организации.
Практика реализованных проектов демонстрирует, что описание бизнес-процессов должно в обязательном порядке иметь заказчиков. Если модели бизнес-процессов создаются без четкого понимания алгоритмов их дальнейшего использования, то, скорее всего, они никем не будут востребованы.
Как правило, описание бизнес-процессов используется для их дальнейшей регламентации (69%) и для совершенствования деятельности (67%). При этом многие компании (40,5%) описывают бизнес-процессы для того, чтобы в дальнейшем их автоматизировать. Положительно то, что, по данным исследования, в настоящее время свыше 28% компаний используют описание бизнес-процессов для внедрения системы менеджмента качества (ISO). Это означает, что компании уже начали совершенствовать свои бизнес-процессы, а не ограничились лишь получением «формального» сертификата.
Для каких задач используются созданные описания бизнес-процессов?
Понятия «функциональный барьер», «процессный подход».
Процессный подход — систематическая идентификация и управление, применяемых организацией процессов и особенно взаимодействия таких процессов. (ISO 9000).
Процессный подход к организации и управлению деятельностью предприятия предполагает ориентацию:
• деятельности предприятия на бизнес-процессы;
• системы управления предприятием на управление как каждым бизнес-процессом в отдельности, так и всеми бизнес-процессами в целом;
• системы качества предприятия на обеспечение качества технологий выполнения бизнес-процессов, в рамках существующей или перспективной организационно-штатной структуры и организационной культуры предприятия.
Преимущества использования процессного подхода
• Повышение ориентации на конечный продукт, заинтересованности каждого конкретного исполнителя в повышении качества конечного продукта и заинтересованность в качественном выполнении своей работы.
• Снижение нагрузки на руководителей, так как ответственность распределяется между владельцами процессов.
• Высокая гибкость и адаптивность системы управления, обусловленные большей саморегулируемостью системы и естественной ориентацией на потребителя.
• Высокая динамичность системы и ее внутренних процессов, обусловленная сильной вертикальной интеграцией ресурсных потоков и всеобщей заинтересованности в повышении скорости обмена ресурсами.
• Снижение значимости и силы действия бюрократического механизма, емкого на временные и финансовые ресурсы.
• Высокая прозрачность и понятность системы управления, а тек же упрощение процедур координации, организации и контроля.
• Возможность глубокой комплексной автоматизации.
«Функциональный барьер»
Наличие четко действующих коммуникаций в организациях способствует решению многих важнейших организационных проблем, в частности координации деятельности отдельных структурных единиц в организации относительно общей цели, обеспечению устойчивых отношений с внешней средой, предоставлению подразделениям организации необходимой рабочей информации и целевых указаний и др.
Однако создание коммуникационных сетей, формирование устойчивых коммуникационных каналов сопряжены с рядом трудностей, вызванных как дефектами в каналах информации, так и дефектным кодированием или декодированием получаемых сообщений.
Проблемы, связанные с созданием эффективно действующих коммуникаций, можно разделить на две основные группы: проблемы структурных коммуникаций и проблемы, возникающие в ходе межличностного общения.
Основная проблема коммуникаций между элементами организационной структуры обусловлена неопределенностью во взаимоотношениях между отдельными структурными единицами организации. При этом распоряжения и директивы руководящего органа организации могут не соответствовать ситуации, не пониматься подчиненными, дублироваться, последующее сообщение может противоречить ранее посланным. Кроме того, в случае неопределенности ситуации горизонтальные связи между отдельными подразделениями или членами организации становятся ненадежными, информация к подразделениям поступает хаотично, что вызывает информационный голод или, наоборот, избыток противоречивой информации. В условиях неопределенности могут усиливаться следующие основные виды барьеров в коммуникационных процессах.
1. Искажение сообщений — явление, при котором в структурные единицы организации поступает информация, не адекватная реальной ситуации.
2. Информационные перегрузки возможны в тех случаях, когда члены организации не в состоянии эффективно реагировать на всю необходимую им информацию и отсеивают определенную ее часть, по их мнению, наименее важную. Однако возможна ситуация, когда именно эта часть информации будет особенно необходима для обеспечения нормального функционирования организации или ее подразделения. Особенно часто информационная перегрузка наблюдается у руководителей, замыкающих на себе решение многих (даже самых мелких) вопросов, связанных с управлением деятельностью подразделений организации.
3. Недостатки в структуре организации оказывают существенное негативное влияние на функционирование коммуникационных сетей. Самым распространенным из таких недостатков следует признать неудачную конфигурацию — существование большого количества уровней управления, когда информация при прохождении от уровня к уровню теряется или искажается.
4. Высокая степень пространственной дифференциации создает преграды для прохождения информации по определенным коммуникационным каналам в силу удаленности отдельных структурных единиц организации. В первую очередь это касается каналов контроля и обратной связи, а также каналов, по которым передается печатная информация (документы, научная или технологическая литература и т.д.).
Решение проблем структурных коммуникаций. Для снижения отрицательного воздействия этих проблем организация может использовать следующие приемы:
1) постоянное регулирование информационных потоков путем создания банка информационных данных, внутреннего рынка информации, пунктов отслеживания и сортировки получаемой извне информации, отслеживания мест информационных перегрузок;
2) контроль за процессами обмена информацией, информационными каналами. Для этого можно проводить такие мероприятия, как разработка плана-графика, периодическая отчетность, регулярные встречи с подчиненными для обсуждения возможных перемен в организации и т.д.;
3) организация системы сбора информации от исполнителей путем создания действующих каналов от подчиненных к руководству, исключающих фильтрацию информации в ходе ее прохождения по структурным уровням. Это возможно с помощью ящиков для предложений, частной телефонной связи, «кружков качества» и т.д.;
4) создание дополнительных каналов для исключения искажения информации или двойственного понимания информационных сообщений путем повторения распоряжений или приказов в специально выпускаемых бюллетенях, информационных листках, регулярных обсуждений или собраний, доски объявлений, демонстрационных витрин, местных средств радио — или телевещания и т.д. Кроме того, полезно вовлекать самих пользователей информации в разработку систем и процедур сбора данных (например, упрощение документооборота, самоконтроль и др.);
5) использование современных информационных технологий, что подводит руководство организаций к решению проблемы создания качественной системы коммуникаций. В частности, к таким мероприятиям относятся внедрение персональных компьютеров на рабочих местах, электронной почты, выход в Интернет, связи с другими организациями и т.д.;
6) планирование рабочих мест с учетом функциональных особенностей и способностей работников. При этом возможно создание коммуникационных сетей у работников, функционально связанных между собой в процессе работы. К таким мероприятиям можно отнести пространственное сближение рабочих мест по принципу технологических линий или цепочек;
7) предотвращение возникновения барьеров между различными подразделениями и должностными статусами в организации, «снятие функциональных и иерархических перегородок». Действительно, снятие различий между «мы» и «они» и понимание организации как единого организма в значительной степени уменьшают трудности в процессе коммуникации.
- Понятие «бизнес-правило». Классификация бизнес-правил.
Бизнес-процесс – это цепочка работ, результатом которой является какой-либо продукт или услуга. В цепочку обычно входят операции, которые выполняются по определенным бизнес-правилам структурными элементами, расположенными на различных иерархических уровнях организационной структуры предприятия.
Под бизнес-правилами понимают способы реализации функций (бизнес-функций) в рамках БП, а также характеристики и условия выполнения БП, т.е., другими словами, бизнес-правила – это специальные сведения и особенности конкретной бизнес-деятельности. Вся бизнес-деятельность должна быть проникнута заботой о потребителе, т.е. в каждом БП должны учитываться требования потребителя (качество, стоимость, условия доставки, особенности использования, сервис и т.д.).
Бизнес-правила – набор условий, которые управляют деловым событием, чтобы оно происходило так, как нужно для предприятия (или клиента).
Клиенты формулируют правила, определяя все возможные и допустимые условия делового события, а также условия, которые недопустимы или нежелательны. Эти правила определяются целым рядом факторов, включая директивы распорядительных органов, промышленные стандарты, деловую хватку и простой здравый смысл.
В качестве примера бизнес-правила в банковском деле можно привести закон, по которому о любой сделке, превышающей сумму 10 000 долларов наличными, государство должно ставится в известность. Бизнес-правила существуют на разных уровнях. Некоторые из них оказывают влияние на всю систему, и многие системы, на самом деле, целиком создаются лишь для того, чтобы ввести в действие бизнес-правила. Бизнес-правила также могут значительно различаться по размерам области влияния. Все бизнес-правила имеют одно общее свойство: они управляют некоторой составляющей бизнеса.
Источник: studfile.net
