Система управления компании бизнес план

Бизнес-план в системе управления предприятием

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

Задача бизнес-плана — дать целостную системную оценку перспектив инвестиционного проекта. С этой точки зрения он выступает как форма представления результатов предварительного технико-экономического обоснования средних и крупных проектов.

Применительно к мелким промышленным и иным проектам он может являться документом, представляющим результаты полного исследования инвестиционного проекта.

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

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

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

Рисунок 1.4. Что должен показать бизнес-план

Необходимый минимум гарантий для инвестора может быть представлен следующим образом:

· Поставленный устойчивый бизнес. После реализации бизнес-плана он должен выйти на новый качественный уровень.

· Управленческая команда. Проект не должен быть ориентирован на одного человека.

· Имущественные гарантии (залог, пакет акций предприятия).

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

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

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

Вышесказанное не означает, однако, что бизнес-план в системе управления компанией связан исключительно с дивизиональными структурами. Нет, принципы управления через бизнес-план позволяют руководителю самому решать, в каком объеме, для каких подразделений, бизнесов или компании в целом применять этот инструмент. В приложении № 1 приведена типология бизнес-планов по целям их реализации.

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

Первое – это то, что существует якобы одна «правильная» структура. Это утверждение верно только в том смысле, что когда речь идет о привлечении внешних инвестиций, то приходится подстраиваться под требования инвестора.

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

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

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

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

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

Рисунок 1.5. Структура бизнес-плана с точки зрения компонентов менеджмента

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

Системы контроля бизнес-плана, — а их две: контроль мероприятий (второй блок) и финансовый контроль (третий блок), — вводятся в систему контроля компании автоматически, то есть интегрируются с существующими системами.

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

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

Таким образом, включая бизнес-план в систему регулярного менеджмента необходимо соблюдение следующих условий:

· Определить организационную структуру, выделить центры финансовой ответственности и связать их с организационной структурой (без этого будет трудно определить субъекты бизнес-планирования)

· Попробовать внедрить бюджетное управление до внедрения бизнес-планирования

· Определить регламент бизнес-планирования, интегрированный с регламентами и форматами бюджетного управления (тогда инструменты бюджетного контроля и регулирования будут и инструментами измерения, контроля и реализации бизнес-плана)

· Разработать и внедрить систему контроля мероприятий. Интегрировать организационный регламент бизнес-плана с системой контроля мероприятий, стараясь не допускать существование в организации двух систем контроля – контроля за реализацией бизнес-плана и контроля за реализацией бюджета

· Использовать схему скользящего бизнес-планирования, т.е. вносить изменения и корректировку бизнес-плана в момент возникновения отклонений от заданных параметров.

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Источник

Проектируем систему управления организации: методология, инструменты, команда

Андрей Недолужко

Управляющий партнёр компании Experts2biz

Эксперт по проектированию архитектуры бизнес и ИТ-систем

Консультант по бизнес-процессам девелопмента и управления недвижимостью

В данной статье речь пойдёт о системном подходе в использовании инструментов в проектах построения системы управления организации.

Основные идеи статьи

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

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

Определение

Прежде, чем рассуждать о системных подходах для построения системы управления организации, необходимо определиться с вопросами «Что такое система управления организации?» и «Зачем вообще нужна система управления организации?»

Что такое система управления организации?

Для начала нужно разобраться, почему «система управления организации». Я рассуждаю следующим образом: организация — это любое искусственное образование, в котором занято более одного человека, которые должны образом организовывать совместную работу для достижения цели. Соответственно, под термином «организация» понимается собирательный образ, обобщающий такие понятия как «бизнес», «компания», «предприятие», «учреждение», «группа компаний», «корпорация»

Теперь ответим на вопрос, что такое система управления организации. К сожалению, существует распространённая ситуация, когда при упоминании термина «система управления организации» у владельцев бизнеса, и руководящих работников возникают ассоциации с информационной системой типа ERP или другим программным продуктом.

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

• Цели (в разрезе объектов управления, цели в области клиентов, партнёров, , оборудования, продуктов, технологий, персонала);
• , посредством которых обеспечивается технология управления;
• Персонал, выполняющий эти , объединённый в организационную структуру;
• Информационные системы и ИТ -инфраструктура (оборудование, системное обеспечение), на базе которой разворачиваются информационные системы управления.

Рисунок 1. Система управления организации

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

Для чего нужна система управления организации?

Есть, по меньшей мере, три веских аргумента:

1. Для того чтобы повысить шансы на успех. Под успехом в данном случае понимается достижение стратегических целей организации с минимальными затратами и сроками. Успешная организация — это не просто та организация, которая достигла своих целей, а та, которая достигла своих целей в разумные сроки и с разумными затратами. Учитывая, что разработка и последующее развитие эффективной системы управления может сократить сроки и затраты на достижение стратегических целей организации, то шансы на успех повышаются. Необходимо отметить, что большинство организаций вообще не достигают своих целей, не говоря о том, чтобы быть успешными. Поэтому, чтобы достичь успеха, организация должна иметь такую систему управления целями, , ресурсами, которая позволяет ей, реагируя на запросы рынка, быстро производить товары и услуги высокого качества и по умеренным ценам;
2. Для того чтобы повысить инвестиционную привлекательность организации или её отдельных проектов. Мы живём в мире, где правит капитал, и даже государственные организации вынуждены привлекать частный капитал для реализации своих проектов, не говоря уже о частном бизнесе. Инвестиции позволяют ускорить процесс развития организации, сократить время достижения стратегических целей, выиграть конкурентную гонку, однако их всегда непросто получить на выгодных условиях. А в условиях финансового кризиса их сложно получить вообще! Прозрачная и эффективная система управления организацией существенно повышает шансы на привлечение инвестиций на очень выгодных условиях;
3. Для того чтобы повысить ликвидность и капитализацию организации. Этот аргумент больше интересен владельцам коммерческих организаций. Ликвидность подразумевает способность легко продать организацию, а капитализация — способность продать дороже. Опять же, прозрачная и эффективная система управления организации существенно повышает ликвидность и капитализацию этой организации и способствует быстрой и выгодной продаже. Автору статьи знакомы компании, стоящие миллионы долларов, владельцы которых не могут выгодно продать их, чтобы успешно «выйти» из бизнеса.

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

Основные проблемы построения эффективной системы управления организации

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

1. Текущее состояние организации. Идея построения системы управления организации может возникнуть у руководства в разные периоды жизненного цикла организации, как в начальной стадии (когда организация только формируется), и на зрелой стадии, когда организация существует уже не первый год. При этом организация может находиться в состоянии бурного развития, а может — в состоянии стагнации. Соответственно, система управления необходима, в первом случае для того, чтобы руководство эффективно справлялось и управляло процессом развития, а во втором — руководство может рассчитывать на выход из состояния стагнации;
2. Нематериальность системы управления организации усложняет оценку и выполнение проекта. В результате проекта мы получаем не здание или сооружение, не производственную линию или автомобиль, а совокупность элементов, выраженных документами, , обученным персоналом. Эта система элементов определяет, как должна работать организация, чтобы быть успешной и достичь своих целей в разумной перспективе;
3. Быстроменяющиеся требования в процессе разработки системы управления. В ходе проекта заинтересованные лица проекта начинают понимать, на каких целях организации нужно концентрироваться, какие процессы можно оптимизировать и выстроить более эффективно, какие изменения нужно внести в организационную структуру, какие элементы информационных систем нужны организации С другой стороны, динамично меняющаяся внешняя среда, которая в современных реалиях вещь вообще трудно прогнозируемая, также заставляет менять требования к системе управления организации. Новые требования к системе управления организации порождают внесение изменений, что, в свою очередь, влияет на содержание, сроки и бюджет проекта;
4. Зрелость менеджмента организации, способность высшего руководства организации обладать единым взглядом на все элементы системы управления организации и проводить согласованную политику в управлении, опираясь на факты.

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

Какую альтернативу можно предложить в подобной ситуации? Другими словами:

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

Решение

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

В этом контексте, следует обратить внимание на существенные изменения (по отношению к предыдущим версиям) в четвёртой версии стандарта по управлению проектами PMBOK, где акцент сделан на то, что реализация подобных проектов должна носить итерационный характер. Другими словами, стандарт PMBOK признаёт тот факт, что гибкие методологии реализации проектов имеют преимущества по сравнению с жёсткими методологиями, построенными по принципу «водопада», где выполнив все работы одной фазы проекта, приступают к следующей. Однако стандарт PMBOK определяет только общие вопросы реализации проектов, и не даёт детальных методических рекомендации по технологии выполнения подобных проектов. Я предлагаю воспользоваться некоторыми идеями и практиками стандартов и методологий из индустрии программного обеспечения, таких как RUP или Microsoft Solutions Framework MSF, адаптировав их под задачи создания системы управления организации.

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

В качестве примера можно привести традиционное концептуальное изображение RUP — Рисунок 2

Рисунок 2. Традиционное изображение методологии RUP

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

Жизненный цикл системы управления организации можно представить следующим образом:

• Анализ и определение требований к системе;
• Проектирование;
• Построение;
• Внедрение;
• Поддержание и развитие.

Соответственно, фазы проекта создания системы управления организации будут аналогичны фазам, определённым в RUP. Однако контекст фаз будет другим — Таблица 1

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

Таблица 1. Фазы проекта разработки системы управления организации

Процессы каждой итерации выглядят следующим образом — Таблица 2.

Название группы процессов	Комментарий
Управление проектом	Процессы управления проектом в соответствии с PMBOK
Выполнение задач в соответствии с BABOK
Определение организации, детальное моделирование и описание её элементов: целей, процессов, показателей, должностей, подразделений, информационных систем , с указанием связей между ними
Разработка документации системы управления организации	На базе полученной формирование документации системы управления организации в виде: положений, регламентов и инструкций, заданий на разработку информационных систем
Разработка информационных систем	Информационные системы могут быть реализованы: На базе существующих на рынке платформ для построения информационных систем; На базе готовых продуктов и их конфигураций; Разработаны «с нуля».
Развитие	Приведение к состоянию, позволяющему эффективно развернуть и использовать необходимые информационные системы

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

Ознакомившись с подобной организацией процессов, можно спросить:

1. Если речь шла об управлении требованиями, то почему нет такого процесса?
2. Где процессы управления качеством, изменениями?.

Дело в том, что именно эти вопросы охватывают процессы и процедуры, описанные в стандартах PMBOK или BABOK,

• Управление проектами согласно PMBOK уже само по себе включает все процессы, связанные с управлением требованиями, качеством, изменениями и интеграцией всех элементов проекта;
• Руководство к своду знаний по (BABOK) делает глубокий акцент на процессах выявления, анализа и управления требованиями, это является одной из ключевых задач .

Таким образом, использование PMBOK и BABOK в качестве базы избавляет от необходимости разрабатывать процессы самостоятельно.

В результате получается следующая концептуальная модель построения системы управления организации, аналогичная RUP — Рисунок 3. Естественно, отображение трудозатрат выглядит несколько утрированно, но, тем не менее, оно даёт представление о том, как распределять ресурсы в ходе выполнения проекта.

Рисунок 3. Итерационный процесс разработки системы управления организации

Место инструментов в проекте

В качестве примера рассмотрим систему Business Studio. Этот продукт предоставляет набор возможностей, который позволяет рассматривать его как центральный инструмент для проектирования верхнего уровня системы управления организации (Рисунок 4).

Рисунок 4. Уровень проектирования системы управления организации

Также Business Studio может использоваться при решении задач на других стадиях проекта:

Фаза	Процесс	Применение
Определение требований	Фиксирование информации, собранной в результате интервью с заинтересованными лицами, относительно их точки зрения на цели, процессы, организационную структуру и информационные системы организации
	«Эскизная» разработка модели организации
	Разработка документации системы управления организации	Подготовка и согласование структуры и внешнего вида
	Разработка информационных систем	Фиксирование видения высокоуровневых элементов информационных систем с точки зрения заинтересованных лиц
Проектирование	Фиксирование информации, собранной в результате ознакомления заинтересованных лиц с эскизом и уточнения требований
	Разработки
	Разработка документации системы управления организации	Подготовка внешнего вида и содержания документации системы управления организации (например, с помощью настройки отчётов в Мастере отчетов Business Studio)
	Разработка информационных систем	Определение структуры информационных систем (собственно, определения списка информационных систем, которые нужны организации); Проектирование высокоуровневой архитектуры этих систем, определения элементов (модулей), из которых они должны состоять, наборов функций, которые выполняются каждым модулем, что в конечно счёте, определяет функциональные требования к информационным системам.
Построение	Ознакомление заинтересованных лиц с результатами проектирования системы управления организации, например, посредством публикации результатов проектирования системы управления в виде и фиксирования в Business Studio результатов обработки «обратной связи» от заинтересованных лиц
	Внесение изменений и развитие
	Разработка документации системы управления организации	Выполнение основного комплекса работ по разработке документации системы для конечных потребителей, всего персонала организации
Внедрение	Внесение изменений и развитие , документации системы управления организации и требований к информационным системам

Таблица 3. Применение Business Studio, на разных фазах проекта

Таким образом, применение системы Business Studio позволяет закрыть целый комплекс задач создания системы управления организации — Рисунок 5.

Рисунок 5. Область применения Business Studio

Команда

Широко распространено заблуждение, что для создания системы управления организации достаточно купить специализированное программное обеспечение (одно или несколько рабочих мест, в зависимости от размеров и целей организации)и обучить специалистов. Однако из рисунков 4 и 5 следует, что возможности современных программных продуктов охватывают различные процессы и, соответственно, области знаний, и для каждого процесса к пользователю системы предъявляются особые требования в плане навыков, знаний и опыта. Поэтому для достижения максимального эффекта в проекте построения системы управления можно выделить следующие роли — Таблица 4.

Роль	Ответственность и основные функции (кратко)	Особенности компетенций и требований к кандидату
Отвечает за процесс и фазу определения требований; Работа с заинтересованными лицами проекта (интервью, опросы, мозговые штурмы, ) с целью: Определения текущего состояния организации; Определения точки зрения заинтересованных лиц проекта на цели, процессы, структуру и другие элементы системы управления организации; Определения потребностей заинтересованных лиц в развитии/совершенствовании системы управления; Определения и дальнейшего уточнения требований к системе управления организации. Оформление требований к системе управления организации и передача их остальным членам команды проекта; Контроль реализации требований в системе; Управление жизненным циклом требований к системе.	Знание стандарта BABOK и умение применять его методы на практике; Развитые коммуникативные навыки; Базовые знания и практический опыт использования систем ; Знание нотаций моделирования и методик управления, поддерживаемых системой .
Отвечает за фазу проектирования, а также за принятие ключевых решений в процессах , , разработки документации системы управления организации, при выполнении других фаз проекта; Определение всех высокоуровневых элементов системы управления организации ( организации) и их взаимосвязей. Отслеживание целостности на протяжении всего жизненного цикла системы управления.	Глубокие знания архитектуры организаций, информационных систем, системного инжиниринга; Глубокие знания в области управления организацией, управления проектами, ; Знание методик и стандартов управления, поддерживаемых системой , практический опыт их внедрения/использования; Знание и практический опыт использования систем ; Развитые коммуникативные навыки.
Специалист по	Отвечает за процесс на всех стадиях проекта; Детальное моделирование элементов системы (карты целей, , организационная структура).	Глубокое знание и практический опыт использования выбранной системы ; Знание нотаций моделирования и методик управления, поддерживаемых системой .
Специалист по разработке документации системы управления организации	Отвечает за процесс разработки документации системы управления организации на всех стадиях жизненного цикла; Настройка и подготовка отчётов в среде для документации системы управления; Формирование документов.	Глубокое знание и практический опыт использования выбранной системы ; Владение навыками программирования в объёме, необходимом для разработки отчётов; Продвинутое владение Microsoft Word и Microsoft Excel.
Специалист по качеству	Отвечает за обеспечения качества в процессах , , разработки документации системы управления организации; Участие в разработке процессов по созданию и развитию системы управления организации; Участие в разработке внутренних стандартов оформления документации системы управления; Контроль правильного оформления документов системы управления.	Базовые знания и практический опыт использования систем ; Знание действующих внешних и внутренних стандартов в области оформления документации; Опыт работы специалистом по качеству, усидчивость, внимание к деталям.

Таблица 4. Роли команды, использующей систему

Как видно из таблицы 4, можно выделить пять ключевых ролей исполнителей, которые будут участвовать в проекте создания системы управления организации. Они выполняют совершенно различные функции, имеют различные зоны ответственности и требования к квалификации. Обеспечение человеческими ресурсами данных ролей — это, собственно, уже другой вопрос, который зависит от объёмов проекта и возможностей организации. Естественно, для небольших организаций некоторые роли могут совмещаться: например, может также выполнять роль или специалиста по (но не две сразу), возможны и другие варианты. Основное правило — не должно быть явного конфликта интересов: например, специалист по разработке документации системы управления не может выполнять роль специалиста по качеству, иначе качество будет страдать. С другой стороны, и для крупных и для небольших организаций можно активно использовать аутсорсинг или инсорсинг ресурсов:

• , или специалист по , специалист по разработке документации системы управления организации могут наниматься как внешние подрядчики — пример аутсорсинга;
• В качестве специалиста по качеству может привлекаться (после дополнительного обучения) сотрудник отдела качества компании — пример инсорсинга.

Заключение

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

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

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

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

Литература:

[1] Якбсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. — СПб.: Питер, 2002 — 496 с. ил
[2] Руководство к своду знаний по управлению проектами (Руководство PMBOK) — Четвётое издание. ©2008 Project Management Institute, Inc
[3] A Guide to the Business Analysis Body of Knowledge (BABOK ® Guide), Version 2.0. ©2009 International Institute of Business Analysis. Toronto, Ontario, Canada

Опубликовано по материалам:
Журнал Intelligent Enterprise № 12, 2012

Источник