- осуществляется поиск "подходящей" программной системы, покупка некоторых модулей такой системы и процесс их внедрения;
- осуществляется поиск "подходящей" компании, занимающейся разработкой программных систем, заключается с ней договор и начинается процесс разработки и внедрения системы "под заказчика";
- осуществляется поиск специалистов в области программирования, прием их на работу и создание ими в качестве сотрудников "своей" информационной системы.
Для начала сформулируем простые вопросы и дадим на них ответы.
КОМУ НУЖНА КОМПЛЕКСНАЯ АВТОМАТИЗАЦИЯ УПРАВЛЕНИЕМ ПРЕДПРИЯТИЯ?
Комплексная автоматизация управлением предприятия нужна лицу, заинтересованному в УВЕЛИЧЕНИИ ПРИБЫЛИ предприятия за счет повышения эффективности принимаемых управленческих решений. То есть, этим лицом может быть либо СОВЛАДЕЛЕЦ предприятия, либо МЕНЕДЖЕР ВЫСШЕГО ЗВЕНА УПРАВЛЕНИЯ, заработок которого напрямую зависит от прибыльности предприятия. В дальнейшем будем называть такое лицо Руководителем (не нужно путать с руководителем среднего и нижнего звена управления, заинтересованность которого носит, в основном, морально-этический характер).
ЧТО НУЖНО ПОЛУЧАТЬ ОТ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ РУКОДИТЕЛЮ?
Для повышения эффективности принимаемых управленческих решений Руководитель должен, в самом простом варианте:
- планировать поступление денег;
- планировать производственную деятельность;
- планировать расходы.
КАКОЕ УСЛОВИЕ ЯВЛЯЕТСЯ НЕОБХОДИМЫМ ДЛЯ АВТОМАТИЗАЦИИ УПРАВЛЕНЧЕСКОГО УЧЕТА?
Система управленческого учета работает на данных, которые поступают с мест выполнения хозяйственных операций или, другими словами, на данных ОПЕРАТИВНОГО УЧЕТА. Для эффективного управленческого учета данные оперативного учета должны, как минимум:
- поступать своевременно;
- интерпретироваться в форме, позволяющей проверить их достоверность;
- храниться в форме, позволяющей составлять аналитические выборки за предыдущие периоды.
КТО ВЛАДЕЕТ ЗНАНИЯМИ ОБ ОПЕРАТИВНОМ УЧЕТЕ НА ПРЕДПРИЯТИИ?
Мы говорим о преуспевающем предприятии. То есть, знаниями о системе оперативного учета владеют руководители нижнего звена управления и сотрудники - "владельцы" бизнес-процессов. Им уже давно (в процессе успешного развития предприятия) делегировали эти полномочия. И, что самое важное, в подавляющем большинстве случаев они владеют "своей частью" и передают ее "методом наставничества" новым сотрудникам, которые появляются как вследствие роста организации, так и вследствие ротации кадров.
МНОГО ЛИ БИЗНЕС-ПРОЦЕССОВ В КОНТУРЕ ОПЕРАТИВНОГО УЧЕТА ПРЕДПРИЯТИЯ?
Если говорить об элементарных бизнес-процессах, то есть бизнес-процессах, которые являются последовательностью операций, выполняемых одним лицом, без привлечения внутри этой последовательности результатов деятельности других бизнес-процессов, то количество таких бизнес-процессов в контуре оперативного учета может исчислятся сотнями, а то и тысячами. И при этом они жестко связаны между собой потоками данных и (или) товарно-материальных ценностей, финансовых ресурсов.
Таким образом, для комплексной автоматизации управления предприятием необходима автоматизация контура оперативного учета с изначальной постановкой четких целей по способам хранения информации, ее агрегирования и передачи в контур управленческого учета. Однако, данная задача, зачастую, становится трудноразрешимой в силу следующих объективно существующих причин:
- Особенности хозяйственной деятельности любого предприятия не позволяют полностью автоматизировать оперативный учет с помощью готовых программных решений. Такие программы необходимо дорабатывать или приводить бизнес-процессы хозяйственной деятельности к стандарту готового решения.
- Бизнес-процессы оперативного учета на предприятии могут быть не описаны в явной форме. Их суть и взаимосвязь находятся на уровне "интуитивных" знаний руководителей нижнего звена и сотрудников.
- При автоматизации оперативного учета руководство этим процессом осуществляется людьми, которые не имеют прямой заинтересованности в конечном результате автоматизации. Они заинтересованы только в облегчении собственного труда и труда своих подчиненных.
Для решения указанных проблем необходимо провести ОБСЛЕДОВАНИЕ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ .
Данная статья не преследует цель описания методологии формализованного описания бизнес-процессов предприятия, однако для общего ознакомления с сутью процесса сформулируем некоторые основополагающие понятия.
Операция
- элементарное действие, приводящее к изменению состояния описываемой предметной области (документы, материальные и денежные активы и т.д.)
Бизнес-процесс
- последовательность операций, независящая на момент выполнения от других операций
Функция
- направление деятельности, для выполнения которого необходимо совершить определенные взаимосвязанные последовательности бизнес-процессов
Деятельность любого предприятия определяется целями, которые можно декомпозировать ("разложить") на функции. Степень декомпозиции должна быть достаточной для того, чтобы впоследствии можно было легко выстроить цепочку бизнес-процессов по выполнению элементарной функции. Вариант дерева функций для одной из предметных областей представлен на рис.1.
Рис.1. Вариант дерева функций
Далее создается иерархическая структура бизнес-процессов "как есть". Фрагмент такого описания для одной из предметных областей представлен на рис.2. Данная структура строится на основании опроса экспертов - руководителей и владельцев бизнес-процессов. Ни в коем случае не следует понимать эту последовательность действий как "делай раз и делай два". В процессе создания структуры бизнес-процессов не раз придется вернуться к дереву функций и внести туда коррективы. Это достаточно трудоемкий итерационный процесс, который является основой качественных аналитических действий в дальнейшем. Если сравнивать обследование с построением дома, то дерево функций - это проект дома, а бизнес-процессы - это материалы для его построения. И если этот проект и материалы будут низкого качества, то в дальнейшем никакое мастерство строителей не поможет.
Рис.2. Фрагмент структуры бизнес-процессов
Для всех элементарных бизнес-процессов должны быть определены "входы" и "выходы", которыми могут являться документы, материальные и денежные активы и т.д. Эти "входы" и "выходы" являются не только элементами предметной области, над которыми совершаются операции бизнес-процессов по их изменению (логика этих изменений должна быть четко описана), но и связями, по которым выстаиваются цепочки бизнес-процессов по достижению функций. Фрагмент такой цепочки представлен на рис.3.
Рис.3. Фрагмент последовательности бизнес-процессов
Все элементарные бизнес-процессы должны быть связаны с владельцем - конкретным элементом штатного расписания организации. Собственно говоря, все бизнес-процессы штатной клетки составляют суть должностной инструкции, которой должен руководствоваться сотрудник, числящийся на данной клетке.
Следующая стадия - это реинжиниринг бизнес-процессов. То есть, необходимо:
- выявить и устранить дублирование операций в ходе последовательности процессов по достижению цели;
- устранить слабую формализацию пооперационного выполнения части бизнес-процессов;
- определить ответственность конкретного сотрудника за бизнес-процесс, если она "размыта" между многими исполнителями;
- определить бизнес-процессы, подлежащие автоматизации.
- Формализованное описание бизнес процессов хозяйственной деятельности предприятия.
- "Выстраивание" элементарных бизнес-процессов в процессные цепочки по достижению целей хозяйственной деятельности.
- Определение "жизненных циклов" документов в виде последовательности процессов их формирования, модификации, использования и хранения посредством описанных бизнес-процессов (формализация документооборота предприятия).
- Анализ полученных описаний и их модификация с целью повышения эффективности хозяйственной деятельности предприятия (реинжиниринг бизнес-процессов).
Полученный результат важен не только как первый шаг автоматизации предприятия, он сам по себе является "гигантским" шагом в налаживании регулярного менеджмента на предприятии (формирование положений о подразделениях, формализация должностных инструкций и т.п.) и основой для построения критериев оценки его эффективности.
И, напоследок, еще немного "о грустном" - о рисках. Предположим, что Вы - Руководитель, осознали важность проблемы, нашли консультантов, финансировали проведение обследования, получили отчет, соответствующий поставленной задаче. А где гарантии того, что полученный результат соответствует действительности, то есть, в описании учтены все бизнес-процессы и их описание позволяет однозначно интерпретировать суть деятельности? Даже если это не так, Вы, конечно, можете утвердить полученные должностные инструкции, можете провести оптимизацию полученных бизнес-процессов и обязать работать организацию по новому. Это, скорее всего, приведет к повышению эффективности - ведь, Вы все равно "продвинулись" в налаживании регулярного менеджмента. Люди поймут поставленные задачи, ведь до этого они работали в условиях устных договоренностей о правилах работы.
Однако, при создании автоматизированной системы по такому описанию могут возникнуть сложности. Ведь, компьютер - не человек. Любая "недоговоренность", неточность или слабо формализованное описание будет "растолковано" компьютеру программистом, и качество такого толкования будет контролироваться не Вами.
Кроме этого, есть еще одна проблема - жизнь меняется, меняется и Ваш бизнес. Если Вы получили результат обследования в виде "кипы бумаг", то оно рискует со временем превратиться в фотографию из старого альбома, которую можно показывать только гадалке, а врачу вместо себя не представишь. Конечно, сложность организации предприятия нельзя сравнивать со сложностью устройства человеческого организма, однако и здесь не все так просто. Для примера предположим, что количества бизнес-процессов документов и штатных клеток измеряются десятками. Уже только для такого небольшого числа количество их взаимосвязей может достигать десятков тысяч. То есть, для того чтобы результат формализации бизнес-процессов "поддавался" анализу и модификации все данные обследования должны заноситься при помощи специальной программы в базу данных, а формы анализа и отчетные формы генерироваться этой программой. Такие программы существуют, например, BPWin.
Для уменьшения рисков, прежде чем начинать проект обследования предприятия с целью формализованного описания бизнес-процессов, желательно соблюсти 3 условия:
- Описание деятельности любого подразделения со стороны заказчика должен утверждать его руководитель, который предварительно предупреждается о персональной ответственности за "свою часть проекта".
- Со стороны исполнителя нужно потребовать краткое предпроектное обследование, результатом которого должны стать предложения о применении возможных типовых решений автоматизации и определение приблизительной суммы проекта по внедрению программного обеспечения.
- Исполнитель должен обладать программной системой, в базе данных которой можно хранить все сложные взаимосвязи между функциями, бизнес-процессами, документами, элементами штатного расписания и т.д. Получив этот инструмент вместе с результатами обследования, Вы будете иметь возможность самостоятельно вести регулярную работу по формализации и анализу изменяющихся бизнес-процессов Вашей хозяйственной деятельности.
Формализация бизнес-процессов как платформа для качественного управления предприятием
Введение
Если проанализировать существующие в настоящий момент системы управления предприятиями в России, то можно сказать, что большинство из них имеют ярко выраженную функциональную направленность. В основе таких систем лежит принцип разделения и специализации труда. Функционально-ориентированные системы, конечно, имеют право на жизнь, но уже концептуально устарели, так как динамика в рыночных отношениях, растущая конкуренция, возрастающие требования клиентов требуют принципиально новой структуры и механизмов управления. И самое главное, что чем крупнее предприятие, тем не эффективней оно начинает работать.
Функционально-ориентированные системы
Для начала следует охарактеризовать функционально-ориентированную систему управления, выделить ключевые моменты, требующие пристального внимания, чтобы стали понятны ее узкие места. Структура практически любой организации включает генерального директора предприятия, который в своем распоряжении имеет (а может и не иметь) определенное количество подчиненных ему директоров и замов. В общем случае предприятие разделено на некоторое количество отделов по функциональному признаку (бухгалтерия, отдел информационного обеспечения, отдел прямых продаж, финотдел и т.д.). В каждом отделе существует начальник или руководитель, несущий непосредственную ответственность перед генеральным директором. Функциональные подразделения состоят из сотрудников, каждый из которых выполняет возложенную на него функцию. В системе с такой структурой каждый занят своим делом — бухгалтерия ведет учет, отдел информационного обеспечения занимается автоматизацией, отдел прямых продаж устанавливает контакты с клиентами. Все эти действия регулируются руководством и в общем случае центральным звеном всей системы – генеральным директором. В этом контексте, конечно, возникает множество бизнес-процессов, которые определяют функционирование предприятия в целом. Проблема в том, что эти бизнес-процессы не формализованы, не документированы, пущены на самотек, не ориентированы на конечного потребителя результата этого процесса. Это является побочным эффектом функционально-ориентированной системы, ведь результаты деятельности отделов и конкретных исполнителей не связаны с результативностью предприятия в целом, целевыми задачами предприятия. Каждый элемент выполняет порученную ему задачу в своем собственном «замкнутом пространстве». Даже если поставленная задача выполнена с наивысшим качеством, ее результат может сказаться на результативности выполняемых задач других элементов системы. Такое положение вещей может даже привести к конфликтам внутри предприятия. Например, когда один отдел может мешать внедрению и реализации задачи другим отделом. Так же следует отметить, что при подобной системе результаты деятельности сотрудников в большинстве случаев принимаются и оцениваются (впрочем, как и различные идеи) руководителем отдела. Сотрудник выполняет порученную ему работу, ориентируясь именно на своего начальника и, как следствие, пытается ему угодить в противовес интересам фирмы в целом и интересам отдельных ее сотрудников, что не допустимо. Взаимодействие отделов происходит не эффективно. Информация при передаче (в устной форме преимущественно) теряется и искажается. Информация может задерживаться или вовсе не передается, иногда даже умышленно блокируется на определенных уровнях. Некоторые функции, выполняемые разными отделами, могут дублироваться (например, в силу организационных причин), что стоит времени и денег. Учитывая вышеперечисленные факты, обмен информацией приводит к большим накладным расходам, длительным сроком выработки различных управленческих решений, в результате чего компания теряет прибыль. Даже если на таком предприятии внедрить АСУ, то в сущности ничего не изменится и назвать это уже можно будет «автоматизированным бардаком», кроме того, возрастут расходы на поддержку и эксплуатацию АСУ, и содержание соответствующих специалистов. Исходя из всех этих фактов, можно и нужно сделать вывод, что существующую функциональную систему следует заменить другой, более эффективной.
Процессно-ориентированные системы
Было сказано, что любое предприятие существует в виде взаимосвязанных между собой процессов. Процессы идут «сами по себе», не документированы, не структурированы и никто за них не отвечает и не несет ответственность. Это не правильно. Любое предприятие, в том числе и не коммерческое состоит из группы взаимосвязанных процессов, которые приводят к достижению ключевых целей и составляют фактическую деятельность предприятия. Под бизнес-процессом следует понимать набор повторяемых операций, которые преобразуют исходные данные в конечный результат в соответствии с правилами этого процесса. Упрощенно каждый бизнес-процесс имеет вход — исходная точка для данных и выход — результат процесса.
Суть в том, чтобы разобраться во всех бизнес-процессах предприятия, формализовать их, построить соответствующую модель деятельности. То есть идея состоит в том, что предприятие можно представить в виде совокупности бизнес-процессов, а сущность управления заключается в управлении этими процессами. В процессно-ориентированной системе нет начальников и подчиненных в том смысле, что конкретный исполнитель отчитывается процессу и только процессу в рамках построенной модели. Следует отметить, что это возможно только при грамотно спроектированной модели. Не существует типового списка бизнес-процессов для конкретного вида предприятия и типовой модели. Каждое предприятие разрабатывает свой собственный список и состав бизнес-процессов и строит свою собственную модель деятельности.
Это позволит в дальнейшем ориентировать процесс на конечного потребителя, устранить побочные явления и дублирующиеся звенья, выявить затратные центры, узкие места, избыточные операции, возможности автоматизации, т.е. решить вышеперечисленные проблемы функциональных систем управления. Подобная реорганизация переводит предприятие на качественно новую платформу, уровень работы и уровень мышления. При этом следует выполнить эту реорганизацию и последующее управление так, чтобы каждый элемент системы не вступал в противоречие с другими элементами и ориентировался на общие цели предприятия. Этого можно достичь только качественной разработкой структуры процессов и распределения функций и ролей. Следует отметить, что существует методологии управления процессами, которые позволяют, как формализовать и процессы и его элементы, так и производить анализ различных показателей процесса. Т.о. качественная и хорошо продуманная процессно-ориентированная система «уравнивает» всех участников процесса между собой и требования к ним, определяя равное качество на всех этапах процесса. В этом случае сотрудник уже не ориентируется на своего руководителя и отчитывается не ему, а процессу и отдельным его элементам. В этом случае уже будет эффективным применение АСУ и информационных технологий с наименьшими затратами.
Эффективно управлять бизнесом без ясного и однозначного понимания всеми сотрудниками бизнес-процессов компании - невозможно!
Согласно определению бизнес-процесс - это цепь логически связанных, повторяющихся действий, цель которых - производство продукции/ оказание услуг (конкретных измеримых результатов) для удовлетворения потребностей внутренних или внешних клиентов. При этом предприятие использует как внешние (сырье, источники энергии, информация), так и внутренние ресурсы (труд работников, технологии, оборудование). Совокупность всех бизнес-процессов представляет собоймодель бизнеса .
Для того чтобы своевременно обеспечить «на выходе» необходимое количество продукции/ услуг требуемого качества, каждый сотрудник должен знать свои обязанности, причем его роль (рамки полномочий и ответственности) должна однозначно пониматься всеми участниками процесса. Иначе невозможно эффективно контролировать деятельность работников и точно оценивать вклад каждого в достижение конечного результата.
В период проведения изменений в компании для адаптации к новым рыночным условиям описание (формализация) и усовершенствование ключевых бизнес-процессов становится особенно важной задачей. Какое же отношение к оптимизации бизнес-процессов имеет менеджер по персоналу?
Безусловно, ответственность за организацию процессов, регламентов и процедур в первую очередь несет руководитель компании. Тем не менее, у линейных менеджеров нередко «не доходят руки» до составления соответствующих регламентов, или они считают, что и без формализованных процессов все сотрудники «и так знают», кто за что отвечает и кто что должен делать. В действительности, когда бизнес-процессы не формализованы, каждый работник выполняет задачи «в меру своего понимания». Грамотное описание всех этапов работы в подразделении позволяет четко установить обязанности сотрудников на конкретных рабочих местах. На основе этих описаний менеджер по персоналу может подготовить фактические должностные инструкции , которые действительно станут рабочим инструментом для сотрудников. При таком подходе мы отталкиваемся от «логики процесса», а не от фантазий руководителя по поводу того, как бы еще «загрузить» подчиненного.
Необходимость формализации бизнес-процессов возникает и при проведении оценки уровня вовлеченности работников компании (или отдельного подразделения). Специалисты по управлению персоналом выявили: один из основных источников неудовлетворенности работой в компании - неэффективная организация труда . Например, не разграничены зоны ответственности, сотрудники выполняют ненужные действия, нарушают технологическую последовательность операций и т. п. В данном случае причина неудовлетворенности работников - управленческие ошибки , а именно: неправильно спроектированные рабочие процессы, которые могут снижать производительность труда, создавать в подразделении конфликтные ситуации, приводить к увольнению ключевых сотрудников, ухудшать удовлетворенность клиентов. Неправильно спроектированные процессы чреваты и такими «побочными эффектами», как недостаток или избыток персонала на различных участках, дублирование одних функций и недостаточное внимание к другим (что также сказывается на результатах - ритмичности работы, производительности труда и качестве продукции/услуг).
Все эти вопросы входят в компетенцию службы по управлению персоналом, а значит, эйчары сами должны инициировать изменения и браться за их решение. Надеюсь, что наш опыт будет интересен в первую очередь коллегам-эйчарам, занимающим проактивную позицию при возникновении проблем в компании и готовым взяться за ту работу, которая во многих организациях традиционно не относится к зоне ответственности отделов по управлению персоналом.
Несколько месяцев назад в нашей компании было принято решение о проведении реорганизации службы поддержки клиентов, чтобы повысить ее эффективность в изменившихся условиях ведения бизнеса. На момент принятия такого решения служба успешно справлялась с поставленными задачами. Тем не менее, с увеличением количества проектов, которые были переданы на поддержку после внедрения1, возросла загрузка консультантов, оказывающих клиентам сервисные услуги, а это, в свою очередь, отразилось на сроках выполнения работ. Также на тот момент в компании прошли кадровые перестановки, и руководством было принято решение об обновлении качественного и количественного состава этой службы. Таким образом, возникла необходимость в кратчайшие сроки провести изменения - без прерывания производственного процесса.
Начиная реорганизацию службы поддержки, мы понимали: нужно избежать описанных выше ситуаций и при этом создать все условия, чтобы новые сотрудники сразу начали работу согласно корпоративным требованиям. Для этого необходимо было организовать для них максимально предсказуемою среду. Прежде всего, формализовать требования к работе - описать потоки информации между ключевыми участниками и задокументировать все процессы и процедуры. Понимая, что руководитель службы должен обеспечить выполнение работ в соответствии с контрактами в чрезвычайно динамичном режиме, специалисты по управлению персоналом компании взяли эту задачу на себя. Наше участие также гарантировало, что мероприятия по формализации бизнес-процессов службы не будут отложены «в долгий ящик».
Поскольку объем работы подразделения резко увеличился, а значит, выросла загрузка консультантов, мы начали искать самый простой, быстрый и наименее затратный метод улучшения бизнес-процессов. Так мы пришли к использованию метода быстрого анализа решения , или методики FAST2. В состав команды FAST вошли руководитель службы поддержки, менеджеры по персоналу и руководитель подразделения, куда входит служба поддержки. Команда определила план действий, приведенный в таблице 1 .
Табл. 1. План действий по методике FAST
|
№ п/п |
Описание |
Ответственный |
| Формулирование целей службы поддержки |
Руководитель подразделения Руководитель службы |
|
| Анализ имеющейся документации, информации | Менеджер по персоналу | |
|
Составление списка бизнес-процессов службы Определение процессов для FAST |
Руководитель службы Менеджер по персоналу |
|
| Разработка блок-схем бизнес-процессов | Менеджер по персоналу | |
| Определение плана мероприятий для реализации процессов |
Руководитель службы Менеджер по персоналу |
|
|
Презентация руководству компании Утверждение предложенных улучшений |
Руководитель службы Менеджер по персоналу |
|
| Описание и документирование процессов | Менеджер по персоналу | |
| Информирование сотрудников подразделения о новых процессах |
Руководитель службы Менеджер по персоналу |
|
| Информирование сотрудников смежных подразделений об изменениях |
Руководитель службы Менеджер по персоналу |
|
|
Обновление квалификационных требований к работникам службы поддержки Проведение оценки исполнения (performance appraisal ) |
Руководитель службы Менеджер по персоналу |
|
| Контроль соблюдения процессов работниками | Руководитель службы | |
| Обеспечение процесса постоянного улучшения | Руководитель подразделения |
В первую очередь мы переформулировали миссию и некоторые цели подразделения, согласовали изменения с руководством компании. В процессе обсуждений были выработаны подходы, которые позволили бы расширить круг заказчиков, и определены дополнительные взаимосвязи с отделами маркетинга и продаж.
Далее мы проанализировали действовавшее на тот момент «Положение о службе поддержки», в котором были описаны утвержденная структура подразделения, должностные обязанности и компетенции консультантов по поддержке. Анализ показал, что:
- Положение, регулирующее повседневную деятельность службы не отражало в полной мере новые требования, выдвинутые сотрудникам.
- Для повышения эффективности службы, необходимо провести ряд мероприятий, направленных на улучшение некоторых бизнес-процессов3 и их формализацию.
Затем были проанализированы система и порядок учета выполненных работ, соответствие квалификации консультантов требованиям, информация об удовлетворенности клиентов оказываемыми услугами и т. п. Результаты анализа стали основой нашей дальнейшей работы по обновлению квалификационных требований к сотрудникам службы поддержки.
На следующем этапе были определены критерии оценки , которые помогут руководству в будущем лучше понимать происходящие процессы и контролировать эффективность работы службы поддержки. Кроме того, были обновлены KPIs, в частности, добавлены следующие:
- Фактическое отклонение по срокам выполнения работ в соответствии с типами поддержки и приоритетами задач.
- Количество оплачиваемых часов (для консультантов по поддержке).
- Показатели удовлетворенности клиентов.
После этого составили список всех бизнес-процессов службы поддержки клиентов и определили те из них, работа над формализацией которых должна быть проведена в первую очередь. Для каждого процесса были идентифицированы ключевые участники ; зоны ответственности каждого из них; взаимосвязи сотрудников службы поддержки с другими подразделениями (например, проектным офисом, менеджером по работе с клиентами, финансовым отделом).
Затем мы приступили к разработке первоначальной версии блок-схем4 этих процессов. Проанализировав первые наработки, внесли в них корректировки, в том числе - в отношении участников процессов и зон их ответственности. Например, было принято решение об аннулировании позиции Helpline Representative (помощника-консультанта) - часть этих обязанностей передали младшим консультантам. В итоге, на основании проделанного анализа блок-схем бизнес-процессов, а также анализа фактической работы сотрудников службы была изменена ее структура - с учетом специфики матричных структур, характерных для проектных организаций (рис. 1 ).
Рис. 1. Изменение организационной структуры подразделения
- Обновление квалификационных требований к консультантам службы поддержки.
- Организация оценки исполнения.
- Обучение новых сотрудников службы поддержки (например, деталям и особенностям ИТ-систем заказчиков).
- Анализ эффективности используемой системы регистрации запросов (при необходимости - внесение изменений или даже замена в будущем на другую систему, более соответствующую требованиям бизнес-процессов).
- Подготовка новой версии «Положения о службе поддержки» (в первую очередь, оно должно отражать все бизнес-процессы подразделения, включая их пошаговое описание).
- Разработка регламента выделения дополнительных ресурсов для выполнения работ.
В результате нами были предложены изменения процесса реализации заявок (рис. 2 ) и процесса взаимодействия с другими подразделениями (рис. 3 ).
Рис. 2. Пример процесса реализации заявок
()
Рис. 3. Пример процесса взаимодействия с другими подразделениями
(представлен в сокращенном виде
)
После этого провели презентацию результатов работы команды FAST для руководителей компании и подразделения (заказчика). Все наши рекомендации получили одобрение руководства. После внесения небольших корректировок (они были сделаны в ходе обсуждения вопроса на уровне топ-менеджеров) руководитель службы поддержки провела презентацию для своих подчиненных. С этого момента служба поддержки продолжила свою работу в рамках обновленного регламента.
Параллельно, на основании полученной информации и принятых решений, специалисты по управлению персоналом подготовили новую версию «Положения о службе поддержки». Обновленная версия Положения содержит следующую информацию:
- организационная структура отдела;
- блок-схемы процессов с их пошаговым описанием;
- квалификационные требования (профили должности, табл. 2 );
- стандартные планы обучения для каждого грейда (табл. 3 ).
Табл. 2. Квалификационные требования к сотрудникам отдела поддержки
(представлена в сокращенном виде
)
|
Вес навыка для должности: |
Грейд 1 |
Грейд 2 |
Грейд 3 |
Грейд 4 |
|
| Профессиональные навыки и знания | |||||
|
Знания предметной области |
|||||
|
Описание тест-кейсов |
|||||
|
Описание тестового сценария |
|||||
|
Умение написать техническую спецификацию |
|||||
|
Проведение тренингов для заказчиков |
|||||
|
Знание и использование проектной методологии |
|||||
|
Общие навыки |
|||||
|
Коммуникационные навыки |
|||||
|
Навыки работы в команде |
|||||
|
Управление временем |
|||||
|
Ориентация на заказчика |
|||||
|
Потенциал |
|||||
|
Способность к обучению |
|||||
|
Проактивность |
|||||
|
Инновационность |
|||||
|
Сертификаты |
|||||
|
221 NAV C/SIDE Introduction |
|||||
|
225 NAV Financials |
|||||
|
226 NAV Installation & Configuration |
|||||
| Количество сертификатов | |||||
Табл. 3. Стандартный план обучения сотрудника службы поддержки
|
План обучения сотрудника для подтверждения грейда 2 |
||||
|
Описание |
Приоритет |
Форма обучения |
Сроки |
|
Введение 2-3
Введение
Что такое бизнес-процесс?
Под бизнес-процессом
модель бизнеса .
должностные инструкции
Формализация компании
Что включает в себя понятие «формализация компании»
?
Далее следует собственноформализация бизнеса
описании бизнес-процессов
.
.
должностные инструкции
органиграмма
Положений о подразделениях
Начнем рассмотрение с концепции IDEF как более простой и доступной в виде большого числа программных продуктов, поддерживающих эту концепцию (BPWIN, БИТ-Мастер, MS Visio и др.).
IDEF технология используется, начиная с конца 1980-х годов. Department of Defense USA (Министерство обороны США) является основным пользователем данной технологии. Ею пользуются также некоторые крупные корпорации в США.
Функции 1DEF могут детализироваться в отдельных схемах, это называется декомпозиция. На самом верхнем уровне это может быть все предприятие, отраженное как один блок, а далее - в отдельной схеме - будут раскрыты различные процессы.
Графически стандарт IDEF0 представляет собой следующую структуру (см. рис.1). Функции (работы, операции) изображаются в форме прямоугольника. Названия функций формируются по стандарту в глагольном выражении (выполнить работу, оформить заказ, сформировать бюджет).
Рисунок №1. Диаграмма в формате IDEF
Каждая из сторон прямоугольника имеет свое предназначение:
- Верхняя сторона - управление (правила, стратегии, процедуры или стандарты, которыми руководствуется работа);
- Нижняя сторона - механизмы (ресурсы, которые выполняют работу);
- Левая сторона - входы (ресурсы или информация, используемые работой для получения результата);
- Правая сторона - выходы (материал или информация, которые производятся работой).
В основу построения диаграмм положен иерархический принцип, который позволяет подвергать описание процесса дальнейшей детализации, до тех пор, пока модель не будет описана настолько детально, как это необходимо для решения поставленных задач (возможность проводить декомпозицию). При этом сохраняется целостность взаимосвязей между элементами процесса, проводится контроль входов и выходов при переходе к разным уровням декомпозиции.
Цель
- Во-первых, нужно получить рисунки («блок-схемы»...), которые мы сможем использовать во время презентаций и обсуждений, а также которыми мы снабдим (дополним) текстовые документы, описывающие процессы: те текстовые документы, которые станут основой для проектирования системы.
К этим рисункам (диаграммам) нужно предъявить следующие требования:
- Они должны достаточно подробно и точно описывать логику процесса. При этом для различных сочетаний требований к «подробности и точности» желательно использовать одни и те же диаграммы.
- Они должны быть понятны, причём одинаково, различными людьми, заинтересованными в работе с этими рисунками. Это, в первую очередь, люди бизнеса (Клиенты, сотрудники организации), чью работу необходимо описать, а также бизнес-аналитики, консультанты и т.п.. В идеале, любой человек, знакомый с использованным способом описания процесса, должен правильно понимать то, что изобразили.
- Во-вторых, необходимо построить «модель» процессов, из которой можно получить не только рисунки, но и, например, текстовые отчёты о составе модели и т.п. Поэтому для описания процесса нужно используем не карандаш и бумагу или их компьютерный аналог: программу - «рисовалку» типа Adobe Photoshop, - а специальное «инструментальное средство моделирования». Традиционно под этим термином известны продукты ARISи BPWin, однако не следует ассоциировать способ описания процессов с конкретным продуктом. Более того, зависимость от конкретного продукта сегодня уже является минусом как самого способа описания бизнес-процессов, так и
что же конкретно мы хотим получить от модели бизнес-процессов?
- Модель должна позволять автоматически создавать отчёты о её составе (например, для оценки затрат на разработку Системы)
- Она должна допускать автоматическую проверку по формальным признакам: в частности, проверку корректности использования элементов модели, логики их связей, полноты модели.
- Она должна обеспечивать возможность электронного обмена моделями и диаграммами (а не только «картинками») между различными инструментальными средствами моделирования (а, следовательно, и между людьми), а также передачу их в Систему.
- Она должна быть достаточно полной и строгой для автоматизированного исполнения соответствующего бизнес-процесса (проигрывания его сценариев) как для целей тестирования (с использованием тестовых исходных данных, внешних событий и т.п.), так и для реального использования, т.е. для «промышленной эксплуатации» описаний бизнес-процессов в Системе.
- Иметь обратную связь с Системой: при внесении в Систему изменений (в т.ч. уточнений), они должны автоматически отражаться в модели. В результате, кардинально меняется назначение модели и жизненный цикл её использования: она продолжает «жить» и после завершения (активного этапа) разработки Системы.
Без обратной связи от Системы модель постепенно отстаёт от того, что работает в Системе на самом деле, и поэтому модель «умирает»: становится неактуальной, а потому - ненужной. На синхронное внесение в модель тех изменений, которые вносятся в работающую Систему по требованию Клиента (и, возможно, самим Клиентом), обычно нет ресурсов. И даже в том случае, если такие изменения вносятся, они могут содержать ошибки, быть неполными и т.п. как следствие любых ручных операций.
И наоборот: наличие обратной связи от Системы к её модели замыкает контур управления Системой, делает реальностью циклическую разработку (round - trip engineering), которая сейчас является необходимым элементом любой серьёзной среды разработки автоматизированных систем.
Достоинство модели бизнес-процессов по сравнению с «моделями компонентов Системы» (к которым нас приучил язык UML) в том, что модель бизнес-процессов создаётся на другом, более высоком, уровне абстракции и позволяет бизнес-аналитикам и клиентам непосредственно участвовать в развитии Системы во время её промышленной эксплуатации, работая в команде на своём уровне понимания: на бизнес-уровне Системы. Т.е. в данном случае для внесения в Систему достаточно большой группы изменений: тех изменений, которые относятся к уровню бизнеса и его логики, - Клиенту уже не нужно самому быть программистом или использовать программиста в качестве переводчика его мыслей на язык машины (и наоборот: с языка машины на язык бизнеса).
Пример бизнес-процесса
В качестве примера я взял крупный магазин по торговле мебелью и его бизнес-процесс "Покупка клиентом товара". На рис. 2 представлена диаграмма этого бизнес-процесса в нотации BPMN, с комментариями по нотации.
Рис. 2. Пример бизнес-процесса
Весь бизнес-процесс разбит на действия, которые изображаются прямоугольниками со скругленными углами. Переходы между действиями показаны стрелками, а документы, которые порождаются или используются каким-либо действием, показаны прямоугольниками с загнутым правым углом. Эти прямоугольники соединены штриховыми линиями с тем действием, в результате которого они созданы, и с теми действиями, в которых они используются.
Выделим следующие действия бизнес-процесса.
1. "Оформление заказа". Сначала клиент оформляет заказ. Предполагается, что перед этим он определился в главном - что ему нужно. Например, кухонный гарнитур. Тогда в отделе по торговле кухонной мебелью он, вместе с одним из менеджеров этого отдела, составляет дизайн-проект для своей покупки (в соответствии с размерами его кухни и своими пожеланиями), уточняет параметры своего заказа и точно определяется с комплектующими и материалами.
2. "Получение товаров". Клиент идет на склад и сам выбирает все составные части своего заказа, имея точный перечень того, что ему нужно. При этом ему помогают работники склада.
3. "Оплата товаров и оформление доставки". Клиент вместе со своими выбранными товарами (он везет их на тележке) следует к кассе и оплачивает то, что он выбрал. Далее, с оплаченными товарами, он переходит в отдел доставки, где оформляет и оплачивает доставку своей мебели, а также ее сборку (если ему это нужно); после этого он уезжает домой.
4. "Доставка". Оплаченные товары клиенту доставляют в течение трех дней.
5. "Сборка". После этого, если клиент оформил сборку, то к нему приезжает мастер-сборщик и собирает доставленную мебель.
На рис. 2 одни и те же документы присутствуют несколько раз. Это сделано из соображений удобства, чтобы не было большого количества линий на диаграмме. Здесь используется концепция загрузки элемента модели на диаграмму, обсуждаемая в предыдущих лекциях: один и тот же элемент модели можно загрузить на диаграмму много раз. При этом соответствующих диаграммных элементов много, а модельный - один.
Введение 2-3
Ø Что такое бизнес-процесс?...............................................................................................2
Ø Причины формализации бизнес-процесса…………………………………………….3
2. Формализация компании…………………………………...………………………3-6
Ø Основные проблемы формализации и методы их решения………………………….5
3. Методы описания бизнес-процесса……………………………………………….6-8
Ø Текстовый формат описания…………………………………………………………...6
Ø Табличный формат описания…………………………………………………………..7
Ø Графический формат описания………………………………………………………...7
4. Языки графического описания бизнес-процессов……………………………...8-13
Ø IDEF (Integration Definition for Function Modeling)…………………………………...8
Ø UML как средство описания бизнес-процессов………………………………………9
Ø еЕРС – событийно-функциональные диаграммы…………………………………...10
Ø Сравнительный анализ нотаций ARIS и IDEF………………………………………12
5. Описание бизнес-процессов как один из этапов автоматизации……………13-15
6. Процедурные карты……………………………………………………………….16-17
7. Пример бизнес-процесса…………………………………………………………..17-19
8. Регламентация бизнес-процесса………………………………………………….19-24
Ø Описание процесса «как есть»…………………………………………………………19
Ø Разработка показателей результативности бизнес-процесса………………………...20
Ø Определение целевых значений показателей результативности бизнес-процесса...20
Ø Формализация проблем бизнес-процесса……………………………………………..21
Ø Разработка регламента бизнес-процесса «как должно быть»………………………..21
Ø Разработка плана внедрения бизнес-процесса «как должно быть» и утверждение всего пакета документов по бизнес-процессу………………………………………...21
Ø Публикация материалов по бизнес-процессу на корпоративном портале………….22
Ø Проведение обучения основных участников бизнес-процесса……………………...22
Ø Введение бизнес-процесса в опытную эксплуатацию………………………………..23
Ø Доработка бизнес-процесса и ввод в эксплуатацию………………………………….23
9. Заключение…………………………………………………………………………….24
10. Литература…………………………………………………………………………….25
Введение
Что такое бизнес-процесс?
Под бизнес-процессом обычно понимают совокупность различных видов деятельности, которые вместе взятые, создают результат (продукт, услугу), имеющий ценность для потребителя, клиента или заказчика. В качестве клиента может быть другой бизнес-процесс.
Совокупность всех бизнес-процессов представляет собой модель бизнеса .
Для того чтобы своевременно обеспечить «на выходе» необходимое количество продукции, услуг требуемого качества, каждый сотрудник должен знать свои обязанности, причем его роль (рамки полномочий и ответственности) должна однозначно пониматься всеми участниками процесса. Иначе невозможно эффективно контролировать деятельность работников и точно оценивать вклад каждого в достижение конечного результата.
В действительности, когда бизнес-процессы не формализованы (не описаны), каждый работник выполняет задачи «в меру своего понимания». Грамотное описание всех этапов работы в подразделении позволяет четко установить обязанности сотрудников на конкретных рабочих местах. На основе этих описаний составляются фактические должностные инструкции для сотрудников. При таком подходе работа осуществляется по принципу «логики процесса», а не от фантазий руководителя по поводу того, как бы еще «загрузить» подчиненного.
Неправильно спроектированные рабочие процессы снижают производительность труда, могут создавать в подразделении конфликтные ситуации, приводить к увольнению ключевых сотрудников, ухудшать удовлетворенность клиентов, а так же приводят к недостатку или избытку персонала на различных участках, дублирование одних функций и недостаточное внимание к другим (что также сказывается на результатах - ритмичности работы, производительности труда и качестве продукции, услуг).
Необходимость формализации бизнес-процессов возникает и при проведении оценки уровня вовлеченности работников компании (или отдельного подразделения).
Причины формализации бизнес-процесса.
Необходимость в описании и оптимизации бизнес-процессов компании особенно остра, если:
Ø Структура организации не отражает реальных процессов ее функционирования
Ø У сотрудников компании нет четкого понимания того, кто и за что несет ответственность
Ø Нет четко построенных связей и взаимодействий между сотрудниками и отделами
Ø Существуют зоны безответственности или дублирования
Ø Различия в административном и функциональном подчинении приводят к проблемам и конфликтам
Ø Эффективность процессов не позволяет предупреждать отрицательные результаты и совершенствовать деятельность
Какие преимущества получает владелец, решивший формализовать свой бизнес?
1. Появление принципиальной возможности роста для компании. Неформализованный бизнес больше 50 сотрудников не вырастает. Точнее вырастает, но ненадолго…
2. Повышение прозрачности бизнеса для владельца и менеджмента.
3. Увеличение привлекательности компании для цивилизованного инвестора.
4. Рост эффективности бизнеса.
5. Возможность отойти от дел: продать бизнес или поставить наемного руководителя.
Формализация компании
Что включает в себя понятие «формализация компании»
?
В первую очередь, необходимо разделить власть в компании на два уровня: законодательную и исполнительную.
Первый уровень – собрание акционеров и его особые структуры. Второй – генеральный директор и подчиненные ему руководители.
Основная задача законодательной власти - ставить стратегические цели наемному менеджменту и контролировать их исполнение, для чего создаются специальные контролирующие органы. Как правило, на этапе становления бизнеса (со)владелец компании принимает участие в ее оперативном управлении. При формализации бизнеса, даже если владелец продолжает управлять компанией, важно четко разделить роли собственника и менеджера. Так, если хозяин бизнеса привлекает ресурсы компании (например, юристов) для решения личных задач, он предварительно должен согласовать загрузку юриста у его непосредственного руководителя и, что особенно важно, оплатить эти услуги из своих личных средств.
Также необходимо разделить финансы компании и личные средства собственников.
Решение этих задач потребует от владельца заметных волевых усилий. Ведь фактически речь идет о его переходе от роли предпринимателя к роли бизнесмена. Нередко этот процесс осложняется противоречиями в позициях разных акционеров, что чревато выходом из бизнеса некоторых из них.
Далее следует собственноформализация бизнеса
, т. е. переход к четким процедурам выполнения тех или иных задач. Очень часто, придя к пониманию, что «в компании бардак», руководители пытаются решить эту проблему путем написания многочисленных должностных инструкций. И не менее часто эти инструкции, за которые привлеченным консультантам заплачены немалые деньги, хранятся в шкафу у HR-менеджера, а в жизни все остается как раньше. Так происходит потому, что нарушена логика процесса формализации.
Любая деятельность компании состоит из конкретных работ, выполняемых сотрудниками. Каждая работа состоит из набора шагов. И если на этапе молодости бизнеса каждый сотрудник выполняет работу «по наитию» - своими, только ему ведомыми методами - то формализация подразумевает, что основные действия работника описаны и он выполняет работу согласно этому описанию. Конечно, речь идет об описании бизнес-процессов
. Именно эта задача - самая первая при создании регулярного менеджмента. Причем применять можно самые разнообразные инструменты и методологии. Параллельно с описанием процессов может проводиться их оптимизация.
Когда основные (приносящие прибыль, выполняемые изо дня в день) процессы в компании описаны, возникает потребность в разработке типовых документов, где будет вестись планирование и учитываться фактический расход материальных, финансовых и иных ресурсов
.
Примером таких документов служат бюджеты, планы продаж и производства, различные корпоративные справочники.
Когда описаны бизнес-процессы и разработаны планово-учетные документы, важно описать потоки информации между ключевыми участниками, т. е. сформировать регламенты обмена информацией
.
Для примера рассмотрим процесс материально-технического снабжения офиса компании: Он включает в себя такие шаги, как сбор заявок от подразделений на закупку канцтоваров, мебели и оргтехники, формирование консолидированной заявки, расчет бюджета закупки, его последующую защиту с возможной корректировкой и исполнение. При этом планово-учетными документами являются заявка подразделения, сводная заявка, бюджет закупки, который включается в бюджет компании. По каждому документу ведется план и факт. Регламент содержит в себе информацию, кто и к какому сроку должен сформировать тот или иной документ и кому передать, например, на подпись.
И только на этапе, когда созданы вышеописанные три типа документов, есть смысл разрабатывать столь любимые многими руководителями и HR-менеджерами должностные инструкции
. Почему только сейчас? Потому что именно в этот момент проясняется полная картина, показывающая, что должен делать тот или иной сотрудник. Используя данный подход, мы отталкиваемся от логики процесса, а не от собственных фантазий по поводу того, чем бы еще «подгрузить» того или иного сотрудника.
Возникает вопрос: а где же в этой логике формализация оргструктуры? Ведь органиграмма
- базовый документ, и часто именно с его создания начинает свою работу HR-менеджер, приходя в молодую компанию.
Особенность состоит в том, что нельзя сформировать жесткую застывшую структуру и на ее основе описывать остальные элементы бизнеса. Обычно на этапе начала формализации за основу берут фактически действующую в компании структуру (часто приходится обновлять органиграмму, чтобы она соответствовала жизни), а затем, по мере описания и развития бизнес-процессов и иных документов, корректируют ее. Соответственно, в несколько этапов проводится процесс разработки Положений о подразделениях
: документов, описывающих назначение, задачи и функции каждого подразделения. Вообще, все вышеописанные документы логически связаны друг с другом, и важно периодически корректировать их для подержания стройности системы.
Основные проблемы формализации и методы их разрешения:
1)внутреннее сопротивление владельцев бизнеса;
2)сопротивление переменам со стороны менеджмента и сотрудников.
Акционерам компании зачастую трудно привыкнуть к новым правилам игры, перестать вникать в детали работы специалистов, командовать через голову, а то и через три. Непросто перестать относиться к компании как к своему наделу, где: «я хозяин - как сказал, так и будет». А ведь у бизнеса своя логика развития и часто для пользы дела нужно совсем не то, что угодно хозяину. И уж совсем трудно привыкнуть к тому, что необходимо оплачивать компании использование ее ресурсов в личных целях.
У менеджмента и сотрудников иные причины сопротивления. Человек всегда боится неизвестного. Если раньше правила игры были понятны, хотя и нигде не прописаны, то что будет теперь? Боятся потерять свой статус, приобретенный за долгие годы. Боятся не пройти «тест» на соответствие новым, более жестким требованиям. Боятся излишней бюрократизации.
Фактически переход к регулярному менеджменту означает смену корпоративной культуры компании. Поэтому в ходе преобразований очень важно не только разрабатывать необходимые документы, но и грамотно работать с людьми - главными участниками процесса. При этом особую роль приобретают методы социально-психологической диагностики, проводимой до начала преобразований. В процессе изменений надо привлекать к работе неформальных лидеров, грамотно подавать информацию персоналу. По мере разработки документов проводятся специальные «внедренческие» тренинги, которые, с одной стороны, обучают персонал работать в новых условиях, а с другой - изменяют корпоративную культуру в нужном направлении.
Методы описания бизнес-процесса.
Описание бизнес процессов можно проводить различными методами:
- Текстовый;
- Табличный,
- Графический.
У каждого формата есть свои преимущества и недостатки.
Текстовый формат описания бизнес-процессов в детальных пояснениях не нуждается. Это описание бизнес-процесса с использованием текста. Основное преимущество таких описаний - гибкость в выражении любых нюансов процесса средствами языка. Фактически для текстовых описаний бизнес-процессов не существует определенных стандартов, и предприятие может использовать любую удобную для него форму структурирования текстовой информации. Из этого следует и основной недостаток - слабая формализация описаний.
Табличный формат описания бизнес-процессов. Для описания процесса в таблицах можно использовать следующий формат:
Графа «№» - показывает порядковый номер функции. Для описания декомпозиции процесса мо
- экономия на масштабе , это снижение издержек, которое происходит в результате увеличения выпуска продукции. Более крупные компании получают скидки за большие объемы, получают больше экономии по маркетинговым и логистическим мероприятиям, распределяются постоянные затраты на большее количество единиц продукции, что приводит к снижению ее себестоимости при общем росте производства.
- эффект диверсификации , это преимущество компания получает в результате большого перечня операций. Например, крупное предприятие может использовать одни и те же виды маркетинговой деятельности ил каналы сбыта для продвижения разных видов продукции.
Вопросы, на которые необходимо ответить:
Какие наиболее важные расходы предполагает бизнес-модель?
Какие из ключевых ресурсов самые дорогие?
Какие ключевые виды деятельности требуют наибольших затрат?
Примеры бизнес-моделей инновационных проектов представлены в приложении Е.
2 Алгоритм формализации бизнес-модели
Инноваторы очень часто не имеют четкой картины своего бизнеса. На начальном этапе они видят одни процессы работы и взаимодействия, в дальнейшем структуры и методы работы могут кардинально поменяться. Для того, чтобы упорядочить начальный хаос в представлении своего стартующего бизнеса и для того, чтобы облегчить дальнейшую работу инноватора по изменению и развитию своего бизнеса авторами разработан алгоритм формализации бизнес-модели, рис. 1
Рис. 1. Алгоритм формализация бизнес-модели
Данный алгоритм включает три уровня. На первом уровне инноватор должен сформулировать самый главный предпринимательский процесс, т.е. процесс формирования денежного потока и определить точку монетизации. Для этого в первую очередь необходимо «понять» рынок. Для этого изучаются потребности, проводится анализ потребительских предпочтений, сегментирование и выделяется целевой сегмент, тестируется новый товар.
Под точкой монетизации понимается тот этап процесса функционирования компании, на котором товары и /или услуги трансформируются в деньги.
Также на первом уровне необходимо определить расстановку сил на рынке: власть покупателя, наличие конкурентов, силу поставщиков. Особое внимание следует уделить компаниям, которые являются или могут стать вашими конкурентами в ближайшем будущем. Следует рассмотреть возможность установления барьеров для копирования инновационного продукта или услуги, как за счет регистрации прав на интеллектуальную собственность, так и за счет сохранение тайны технологического, технического или другого вида ноу-хау.
На втором уровне следует разобраться с внутренними бизнес-процессами, используемыми технологиями и ресурсами. Здесь следует понять какие ресурсы нам необходимы для производства того объема продукции, который готов удовлетворить начальный рыночный спрос, какого качества должны быть эти ресурсы, где можно найти поставщиков, которые готовы поставит нам ресурсы требуемого качества и количества. Особое внимание стоит уделить человеческим ресурсам, т.е. персоналу вашего предприятия. Поскольку не всегда удается найти необходимое количество специалистов требуемой квалификации, а именно от работы персонала зависит конечный результат деятельности предприятия.
Третий уровень позволяет увидеть взаимосвязь важнейших элементов бизнес-системы предприятия и интегрировать эти элементы в рамках одной схемы. Здесь необходимо определить 9 элементов (по модели А.Остервальдера): потребительские сегменты, взаимоотношение с клиентами, каналы сбыта, ценностное предложение, ключевые виды деятельности, ключевые ресурсы, ключевые партнеры, структура издержек и потоки поступления доходов.
Вопросы, на которые необходимо ответить в процессе разработки бизнес-модели.
Уровень 1. Определение продукта и точки монетизации
Определить продукт / услугу (Что будет продаваться на рынке).
Определить кому требуется этот продукт /услуга (потребителя).
Определить сколько потребитель может и готов платить за данный продукт / услугу
Провести сегментацию (выделить группы потребителей)
Есть ли аналоги на рынке, какие есть конкуренты
Уровень 2. Определение затрат
2.1 Определение технологию производства продукта (оказание услуги)
2.2 Определить необходимые ресурсы
2.3 Определить стоимость необходимых ресурсов для производства единицы продукции
2.4 Найти поставщиков
Уровень 3. Создание системы
3.1 Определение 9 элементов бизнес-модели
3.2 Определение взаимосвязей и процессов между элементами бизнес-модели.
Перспективы развития бизнеса
Необходимо определить перспективные направления развития бизнеса:
Выделить перспективные сегменты рынка;
Показать направления развития продуктов и технологий компании;
Представить шаги по развитию продукта, технологии и бизнеса в целом.
