Показаны сообщения с ярлыком процессная структура. Показать все сообщения
Показаны сообщения с ярлыком процессная структура. Показать все сообщения

вторник, 25 июля 2023 г.

Agile. Гибкие методологии

 


Что такое гибкие методологии разработки

Гибкая методология разработки (Agile software development) – манифест, содержащий основные ценности и принципы, на которых базируются подходы к управлению проектами, который решает проблемы традиционного проектного менеджмента. Agile подходит для инновационных проектов. Гораздо меньше он подходит для процессной деятельности. Эти подходы подразумевают интерактивную разработку, с периодическими обновлениями требований от заказчика и их реализацию посредством самоорганизующихся команд, сформированных из экспертов разного профиля. Под термином «гибкая методология разработки» следует понимать подходы на основе данного манифеста, или фреймворки. Существует множество фреймворков, подходы которых базируются на Agile, например: Scrum, Extreme programming, FDD, DSDM... Данный манифест – разработка команды авторов. (Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas).

Суть Agile

Методология Agile создана как противоположность традиционной линейной методологии «водопад», подразумевая итеративную и пошаговую разработку ПО, что минимизирует риски. Суть в том, что работа с применением гибкой методологии состоит из серии коротких циклов (итераций), длительностью 2-3 недели. Каждая итерация включает в себя этапы планирования, анализа требований, проектирование, разработку, тестирование и документирование. По завершению каждой итерации команда предъявляет заказчику «осязаемые» результаты работы, например, первичную версию продукта или часть функционала, которую можно посмотреть, оценить, протестировать, а потом доработать или скорректировать. Итого заказчик контролирует разработку и может на неё сразу влиять. После каждого этапа, на основе проделанной работы, команда подводит итоги и собирает новые требования, на основании чего вносит корректировки в план разработки продукта.

Ценности и принципы манифеста

Манифест гибкой методологии определяет четыре основные ценности и 12 принципов для методологий, базирующихся на нем.
Ценности:

  • Люди и взаимодействие важнее процессов и инструментов.
  • Работающий продукт важнее исчерпывающей документации.
  • Сотрудничество с заказчиком важнее согласования условий контракта.
  • Готовность к изменениям важнее следования первоначальному плану.

Основополагающие принципы Agile-манифеста:
1. Наивысшим приоритетом является удовлетворение потребностей заказчика.
2. Изменение требований приветствуется на любой стадии разработки. Изменения обеспечивают заказчику конкурентные преимущества.
3. Работающий продукт следует выпускать как можно чаще.
4. На протяжении всего проекта разработчики и заказчик должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные специалисты. Для этого необходимо создать условия, обеспечить поддержку и доверять.
6. Для эффективного обмена информацией с самой командой и внутри команды подходит непосредственное общение.
7. Основной показатель прогресса – работающий продукт.
8. Процесс разработки должен быть постоянным и устойчивым.
9. Внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Минимизация лишней работы.
11. Только самоорганизующиеся команды предлагают лучшие архитектурные и технические решения.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Когда использовать Agile?

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

Чем Agile-методологии нравятся маркетологам


Около 21% отделов маркетинга американских компаний используют в повседневной работе гибкие методологии или так называемые Agile-методологии. Около 52% внедрили их некоторые элементы. Таковы данные онлайн-опроса, который в феврале 2016 года провела компания Wrike, разработчик IT-платформы для командной работы.

Наиболее широко Agile используют сегодня высокотехнологические компании, где поток новых проектов наиболее интенсивен. Но, судя по исследованию Wrike, участие в котором приняли 803 маркетолога, эти техники все активнее проникают и в другие бизнес-сферы. Главные сдерживающие препятствия, по мнению участников опроса: недостаточный уровень осведомленности об Agile (23,5%), привычка работать по старинке (17,6%) и непонимание руководством ценности гибких методологий (11,6%).

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


Agile: как сделать гибкой всю вашу компанию




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

Один из основных принципов Agile отражен в названии, и говорит о таком свойстве, как гибкость. Что такое гибкость применительно к системе управления? Хочу предложить следующую интерпретацию.

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

Чем важна гибкая методология управления

Способность быстро меняться – ключевая в конкурентной борьбе. Определяющий фактор – скорость принятия решений и их последующая реализация. Очевидно, что чем самостоятельней подразделения могут принимать решения, чем меньше согласований им вменено, тем быстрее бизнес развивается. Важна оперативная независимость от центра принятия решений (ЦПР). И не важно, является ли центром принятия решений один человек, в виде генерального директора, либо некая структура в виде управляющей компании.

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

Принципы, лежащие в основе Agile, неплохо ложатся в основу управленческой платформы, построенной на новой методологии управления. Вот некоторые из них:

  • Подразделениям делегируется возможность принимать самостоятельные решения.
  • Акцент на результате, а не на процессе.
  • Контроль результата на каждом шаге.
  • Постоянное упрощение алгоритмов взаимодействия подразделений между собой.
  • В формировании управленческой структуры важен не статус сотрудника, а уровень профессионализма.

Главные правила внедрения agile-управления

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

  • Правило маленьких шагов. В портфолио каждого управленца есть несколько образцовых кейсов, описывающих, как умирают масштабные проекты изменений, так и не дожив до победы. Но Agile категорически не нужны большие и редкие победы. Не стесняйтесь ставить маленькие и очень понятные цели. Даже если цель – просто вовремя начинать и заканчивать совещания.
  • Правило максимальной итерационности шагов. Итогом каждого шага по развитию проекта должен быть результат, уже на этапе предварительного результата устраивающий все группы лиц, иное может обнулить всю работу.
  • Правило «Договорились – делаем». Крайне важный пункт. Никто в одностороннем порядке не отменяет никаких договоренностей. Организатор совещания не может вдруг его пропустить с посылом «вы сами как-нибудь все обсудите, а я потом все пересогласую». Двойные стандарты – первый враг самоуправляющихся систем.
  • Правило «Для народа и с народом». Важно учитывать интересы каждого участника процесса, а не просто спускать инициативу сверху. Равноправие каждого участника процесса принципиально. Все попытки кем-либо продавить «удобное» или «правильное» решение, обнулят активность людей на корню, сделав всю систему принятия решений крайне ригидной и сопротивляющейся. Это касается и первого лица: ничто так не душит на корню желание сотрудников быть гибкими, как «царские указы».

Как начать движение к системе, основанной на гибких принципах

Далее я предлагаю семь шагов, позволяющих начать внедрение принципов СУС в компании. Их последовательность может быть разной. Каждый управленец-практик понимает, насколько жизнь далека от теории. Но главное при этом не впасть в соблазн вообще не делать какие-то обязательные шаги в надежде, что «все образуется само».

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

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

Шаг первый: подготовка к делегированию полномочий

Цель – начать процесс снижения участия первого лица в принятии оперативных решений.

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

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

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

Шаг второй: начать диалог с сотрудниками

Цель – определить, под какие блоки задач на данном этапе есть люди, а где провал. Люди – основа СУС.

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

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

Шаг третий: разработать финансовую модель

Цель – создать единое понимание того, как считаются деньги в компании.

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

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

Рекомендации руководителю. Если вам, как первому лицу, кажется, что экономическая модель компании уже существует, проверьте себя простым вопросом: все ли ключевые люди вашего бизнеса (топ-менеджмент, при наличии) согласны с методикой ее формирования? Или вот вопрос для самых отважных: все ли ваши топ-менеджеры согласились бы с утверждением, что они владеют достаточным объемом информации о том, как рассчитываются экономические результаты, и что их мнение при этом учитывается? Очевидно, что если в этом фундаментальном вопросе вы решили все «царским указом» – нет у вас ни мотивированной команды, ни самоуправления. И, конечно, я молчу о тех случаях, когда финмодель – тайна за семью печатями, которой босс ни с кем не делится.

Шаг четвертый: конкретизировать задачи команды

Цель – создать предпосылки для формирования целей на определенный период.

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

Часто руководитель, действующий в таком стиле, весьма непоследователен и противоречив: сегодня одно, завтра – другое. И менеджмент, после нескольких безуспешных попыток успеть за ним, просто опускает руки и ждет. Первое лицо постоянно что-то меняет, что окончательно демотивирует людей, гасит потенциал команды. Как следствие, руководитель становится одной из точек блокирования СУС, одним из «узких» мест в развитии бизнеса в целом.

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

Данный шаг – это попытка начать фиксировать понимание того «куда идем и какие задачи решаем», хоть в неком, пусть незначительном временном периоде.

Шаг пятый: создать архитектуру бизнес-процессов верхнего уровня

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

На данном этапе начинается формирование предпосылок для перехода системы менеджмента на новый уровень самоуправления. Речь идет о создании верхнего уровня системы управления, о нарезке структуры компании блоками крупных задач, опираясь на основные бизнес-процессы. Изначально блоки обычно выглядят максимально крупно, без общих слов. Пример для производителя электроники: финансы, коммерческая активность, R/D, производство, управление качеством.

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

Шаг шестой: установить границы и правила

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

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

В целом это весьма понятная задача. Самое сложное – в течение определенного времени дать возможность людям и подразделениям поработать в соответствии с принятыми решениями. Это может быть что-то совсем простое: раньше директор каждый день интересовался, как дела в подразделении, теперь – раз в неделю.

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

Рекомендации руководителю: на этом этапе решите, какие именно полномочия вы готовы реально передать, и не вмешиваться некоторое время в деятельность своих подчиненных.

Шаг седьмой: построить систему мотивации команды

Цель – сформировать видение того, что является, по мнению всех заинтересованных сторон, справедливой оценкой результата.

Очевидно, что построение команды, основанной на принципах СУС, это игра в долгую. Также очевидно, что невозможно удержать, знающих себе цену профессионалов, не решив денежный вопрос. Это непростая задача, у каждой из сторон есть свои доводы. Но, откладывая решение «на потом», вы рискуете запустить неуправляемые процессы.

Это тот случай, когда уместно вспомнить поговорку: «жадность приводит к бедности». Как вы платите людям, так они и работают. И чем выше по уровню профессионал, тем сильнее его оскорбляет несправедливость. Он либо уходит из компании, либо объявляет итальянскую забастовку. А вы получаете очередную точку блокировки формирования СУС.

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

Шаг восьмой: запланировать новый цикл улучшений

Цель – планирование следующего шага на пути к самоуправляющейся системе.

Основная задача всей активности, связанной с формированием СУС, это последовательное движение. Безостановочное. Не должно быть иллюзий, что этот процесс будет сам себя поддерживать. Как писал я в статье о термодинамике и управлении, энергия в системе затухает. Задача первого лица – постоянно поддерживать движение этого процесса. И при этом важно, чтобы активность руководителя затрагивала все больше процессов и людей.

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

Выводы

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

Как внедрить Agile в производственной компании




понедельник, 16 марта 2020 г.

Процессы для аналитиков. Часть 1. Понятие процесса




«Все модели – неправильные, но некоторые из них могут быть полезны»
© George E. P. Box
Занимаясь бизнес-анализом, я постоянно имею дело с процессами. В этом нет ничего удивительного: процессы лежат в основе системного и бизнес-анализа.

Предисловие

В предисловии к книге С. Оптнера «Системный анализ для решения деловых и промышленных проблем» С.П. Никаноров еще в 1969 году написал: «… то, что прежде всего должно быть выделено, если мы хотим думать и действовать системно, есть процесс. Не может быть системного мышления без ясного понимания процесса»
Кстати, С. Оптнер считается одним из отцов-основателей системного анализа, а С.П. Никаноров – крестным отцом системного анализа в бывшем СССР.
Я давно собирался написать цикл статей, в котором были бы собраны полезные теоретические и практические знания о процессах. Долгое время меня останавливала мысль, что результатом этой работы станет описание еще одного «неправильного подхода» (см. эпиграф) к описанию и анализу процессов.
С другой стороны, я постоянно сталкиваюсь с множеством других «неправильных подходов». Я понимаю, что новичку в системном и бизнес-анализе бывает порой сложно ориентироваться в огромном количестве информации по этой теме. Надеюсь, что предложенный здесь подход будет интересен и полезен системным и бизнес-аналитикам.

1 Несколько важных вопросов о процессах


На семинарах по процессам я часто предлагаю слушателям описать своими словами ситуацию приготовления яичницы. Как правило, вопрос не вызывает затруднений; слушатели перечисляют необходимые действия: приготовить продукты, разогреть сковороду на плите, разбить яйца, посолить, снять сковороду с плиты, переложить яичницу в тарелку.
На следующий вопрос – сколько в ситуации процессов? – как правило, дается уверенный ответ – один процесс.
На первый взгляд, ответ логичен. Действительно, на выходе мы имеем приготовленную яичницу, следовательно, все действия, которые необходимы для ее приготовления, можно рассматривать как один процесс.
С другой стороны, входы и выходы процессов значительно более многочисленны и многообразны, чем представляется на первый взгляд. В книге Г. Нива. «Организация как система. Принципы построения устойчивого бизнеса Эдварда Деминга» обозначена проблема неадекватности описания процесса из-за неточной идентификации, слабого анализа и обоснования целесообразности учета влияющих на результат (выход) процесса факторов (входов).


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

В связи с этим примером возникает резонный вопрос: сколько же на самом деле входов и выходов нужно указать, чтобы адекватно описать тот или иной процесс?
Возвращаясь к примеру с приготовлением яичницы, мы также можем задать несколько интересных вопросов:
  • Нужно ли учитывать повара в рамках процесса приготовления яичницы?
  • Должны ли мы анализировать, что происходит с плитой и сковородой после завершения приготовления яичницы? А что происходит с поваром?
  • Нужно ли принимать во внимание, что приготовление яичницы осуществляется на основании рецепта из поваренной книги? И что происходит с рецептом после завершения процесса?
Сталкиваясь с более серьезными ситуациями, например, с необходимостью описать процессы компании, мы можем сформулировать еще несколько важных вопросов:
  • Сколько процессов есть в организации?
  • Как различные процессы в организации взаимодействуют друг с другом?

2 Процесс

2.1 Популярное определение процесса

Существует несколько десятков различный определений понятия процесс. Пожалуй, наиболее популярным сегодня является определение, представленное в международном стандарте ИСО 9000:2005:
Процесс — совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующих входы в выходы.
Примечания:
  1. входами к процессу обычно являются выходы других процессов;
  2. процессы в организации, как правило, планируются и осуществляются в управляемых условиях с целью добавления ценности;
  3. процесс, в котором подтверждение соответствия конечной продукции затруднено или экономически нецелесообразно, часто относят к «специальному процессу».
Простой анализ показывает, что данное определение не позволяет ответить на сформулированные выше вопросы. Очевидно, что требуется другой подход к процессам.

2.2 Процессный объект

Я использую следующее определение процесса:
Процесс – это последовательность функций по преобразованию процессного объекта.


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

2.3 Цели процесса

Как правило, в бизнес-анализе мы сталкиваемся с искусственно созданными процессами. Например, процессы в организации созданы для достижения целей, определенных владельцами и/или руководителями этой организации.
В общем виде целью процесса в организации является получение на выходе процесса требуемого состояния процессного объекта.
Рассмотрим процесс перевозки груза. Руководитель транспортной компании определяет цель процесса: груз в нужное время находится в нужном месте.
Рассматривая естественные процессы, например, процессы, протекающие в природе или космосе, мы можем наблюдать направленное преобразование процессного объекта до какого-то конечного состояния.
Направленность преобразования процессного объекта является свойством любого процесса. Искусственно созданные процессы являются целенаправленными. При создании такого процесса учитывается направленность преобразования процессного объекта к целевому состоянию, т.е. к цели, установленной для данного процесса.

2.4 Границы процесса

Поскольку процесс представляет собой целенаправленную последовательность преобразований объекта, границы процесса определяются начальным и конечным состояниями процессного объекта.
Как было показано выше, конечное состояние процессного объекта одновременно является его целевым состоянием. Следовательно, одна из границ процесса определяется целью этого процесса. Эту границу условно можно назвать конец процесса.
Определение другой границы – начального состояния процессного объекта и, соответственно, начала процесса – зависит от конкретной ситуации. Так, если мы рассматриваем ситуацию по описанию процессов организации, то обычно начало процесса – это тот момент времени, когда процессный объект попадает в организацию.
Например, рассматривая границы процесса «найм нового сотрудника», мы можем определить в качестве процессного объекта «сотрудника». Целевое состояние этого объекта – «нанятый сотрудник». Соответственно, «нанятого сотрудника» мы можем рассматривать как конечную границу процесса. В качестве начальной границы процесса мы можем рассматривать «кандидата на должность сотрудника». Таким образом, процесс «найм нового сотрудника» представляет собой последовательность действий (функций) по преобразованию «кандидатов» в «нанятых сотрудников». 
На практике также распространены случаи, когда процессный объект порождается уже внутри организации другими процессами.
Например, компания занимается розничной продажей электронных компонентов со склада компании. Процессным объектом поставок является партия электронных компонентов для заказчика. Однако будет ошибкой считать, что процесс поставок начинается с момента попадания электронных компонентов в компанию, т.е. при закупке. Дело в том, что партия электронных компонентов для заказчика формируется на складе, где и начинается процесс поставки заказчику. В рамках же закупок также осуществляется процесс поставки партий электронных компонентов от поставщика на склад компании. Но в процессе поставки заказчику и процессе поставки от поставщика речь идет о совершенно разных партиях электронных компонентов, т.е., о разных процессных объектах. Соответственно, процесс поставки партий от поставщиков заканчивается на складе компании; процесс поставки партий заказчику на складе начинается.
И совершенно другая ситуация с процессами и их границами будет в том случае, когда компания занимается закупкой электронных компонентов «под заказ». 
Особый интерес представляют ситуации, когда процессный объект может покидать организацию, а затем возвращается назад.
Например, бумажный договор с заказчиком может быть подготовлен и подписан в организации, затем отправлен на согласование заказчику, т.е., покидает организацию, а затем может вернуться в организацию уже подписанный со стороны заказчика.
Подобная ситуация может возникать в производстве изделий, когда какие-то операции с изделиями, например, нанесение покрытия, производятся субподрядчиками.
Другими словами, предварительно следует провести детальный анализ жизненного цикла процессного объекта и уже на основе данных анализа определить стартовое состояние процессного объекта и, соответственно, начальную границу процесса.

2.5 Функции

Процесс представляет собой последовательность преобразований объекта. Каждое отдельное преобразование процессного объекта представляет собой функцию процесса или, наоборот, каждая функция процесса осуществляет некоторое преобразование процессного объекта.


Описывая функцию процесса, мы должны представлять, что она преобразует состояние объекта: начальное состояние объекта на входе в конечное состояние объекта на выходе функции.
Есть функции, которые объединяют два и более объекта в общий объект. Такие функции часто называют функциями сборки.
Например, функция «приклеить подошву к ботинку» на входе имеет два объекта: «подошва (с клеем)» и «ботинок». На выходе функции мы будем иметь один общий объект – «ботинок с подошвой». 
Есть функции, которые, наоборот, осуществляют разделение объекта на несколько частей. Такие функции часто называют разделительными функциями.
Например, функция «распаковать изделие» на входе имеет один объект: «упакованное изделие». На выходе функции мы будем иметь два объекта: «распакованное изделие» и «упаковка» («макулатура», «отходы упаковки»). 
Примечание: далее будет показано, как функции сборки объединяют несколько процессов, а разделительные функции могут порождать новые процессы.

2.5.1 Правила формулирования функций

1. Формулировка функции должна представлять собой отглагольный оборот
глагол + существительное
Например, «вносить данные в форму», «отправить факс контрагенту», «впаять предохранитель в плату» и т.д.
2. При формулировке функции следует избегать употребления глаголов-лозунгов, т.е., таких глаголов, которые не отражают преобразование процессного объекта.
Например, не нужно использовать такие формулировки функций как «организовать выполнение проекта», «обеспечить срок выполнения задачи».
3. При выборе глагола для функции необходимо следить за тем, чтобы он отражал конкретное действие, то действие или преобразование, которое имеет место в действительности.
Например, описывая процесс изготовления ботинка, очень важно не просто сформулировать функцию «прикрепить подошву», а необходимо указать каким именно образом происходит это прикрепление (пришиванием или приклеиванием). Правильная формулировка функции отражает характер изменения объекта: не «прикрепить подошву», а например, «приклеить подошву».
Если предприятие занимается сборкой продукции из закупаемых комплектующих, то правильная формулировка функции будет «собирать продукцию» (например, телевизионные или радио-приемники). Не стоит ограничиваться стандартной формулировкой «производить продукцию». Надо попытаться конкретизировать функцию, отразить в формулировке специфику производимого действия: «собирать телевизионные приемники».
4. В формулировке функции следует избегать использования каких-либо параметров процессного объекта.
Например, формулировка «измерить температуру объекта» содержит параметр объекта – температуру. Но данная формулировка функции не отражает тех действий (преобразований), которые совершаются в рамках процесса. На самом деле, в рамках процесса выполняется функция, которую можно сформулировать как «записать показания термометра». Использование в формулировке функции параметра может привести к искажению понимания этого и процесса и других процессов, связанных с ним.

2.6 Ресурсы

А как быть с другими объектами, необходимыми для выполнения функции? Другие объекты, которые актуализируются как входы и выходы процесса, являются ресурсами.


Ресурсы – это те инструменты, с помощью которых функция осуществляет преобразование процессного объекта.
Важной характеристикой объекта, который является ресурсом функции, является то, что объект-ресурс непосредственно не становится частью объекта на выходе функции.
Например, при выполнении функции «приклеить подошву к ботинку» задействованы объекты: «пресс» и «рабочий». Никакая часть «пресса» и «рабочего» не становится частью «ботинка с подошвой», которые мы получаем на выходе функции. Объекты «пресс» и «рабочий» являются ресурсами нашей функции. Иногда для таких объектов применяется термин инструмент. 
При этом практически всегда после выполнения функции объект-ресурс тоже изменяется.
Например, в рассмотренном выше примере объект «пресс» при выполнении каждой операции по приклеиванию подошвы изнашивается. Это явление даже имеет свое отражение в управленческом учете в виде амортизации оборудования. Объект «рабочий», выполняя операции по приклеиванию подошвы, тоже изменяется – он устает. После завершения смены рабочий восстанавливает свои силы.
Изменение объектов-ресурсов означает, что эти объекты являются процессными объектами каких-то других процессов.
Например, «пресс», который выступает в качестве объекта-ресурса в рамках процесса производства ботинок, является процессным объектом в рамках процесса жизненного цикла оборудования обувной фабрики. Точно так же рабочий выступает в качестве процессного объекта в процессе «управление персоналом».
Таким образом, мы можем сделать вывод, что функция процесса представляет собой узел, в котором пересекается несколько процессов: рассматриваемый процесс, а также процессы, которые поставляют ресурсы для выполнения этой функции.

Заключение

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