Известно, что определение показателей (характеристик) качества процессов, продукции и системы качества в целом необходимо, прежде всего, для проведения мониторинга и измерения в системе качества вуза. В представлено определение термина «мониторинг» - это постоянное наблюдение за каким-либо процессом с целью выявления его соответствия желаемому результату. В стандарте ГОСТ Р ИСО 9000-2008 нет определения термина «измерение», но есть определение «процесса измерения» - это совокупность операций для установления значения величины.
К.М.Рахлиным был сделан анализ многочисленных трактовок понятия «измерение», в результате которого он выделил три группы. В первую группу входят определения наиболее общего характера, например: «Измерение предполагает сравнение объектов в определенном отношении». Во второй группе определений главным признаком измерений называют выражение результата числом. В третьей группе измерение связывается с обязательным наличием единицы измерения или эталона. Все эти группы не противоречат друг другу, но отражают особенности измерения различных объектов. Переход от первой группы определений к третьей есть переход от менее строгих к более строгим представлениям об измерении.
В соответствии с этими группами определений можно выделить три уровня измерений . Первый уровень предполагает сравнение объектов по наличию или отсутствию у них исследуемого свойства с использованием методов номинации, классификации и нумерации. На втором уровне происходит сравнение объектов по интенсивности проявляемых свойств с использованием методов шкалирования, упорядочивания, топологии. Третий уровень предполагает сравнение объекта с эталоном. Следовательно, третий уровень измерений является объектом метрологии.
Существуют различные классификации видов измерения. Так, К.М.Рахлин предлагает выявленные им три уровня измерений подразделить на физические и внефизические (метрические и неметрические). К внефизическим относятся все экономические и социально-экономические измерения . Именно эти измерения, в основном, и осуществляются в системе качества вуза.
Здесь мне хотелось бы упомянуть о следующем. В ряде отечественных публикаций, касающихся методологии измерений, указывается , что измерением понимают сравнение путем эксперимента измеряемой физической величины с однородной (одноименной) физической величиной, принятой за единицу. Поэтому говорить об измерении, без измерений с помощью средств измерений, В.И.Колмановский считает невозможным, и все другие измерения правильнее называть процедурой оценки соответствия. Но в работах Ю.П. Адлера и
В.Л.Шпера , которую критикует В.И.Колмановский, как раз высказывается противоположная точка зрения, и оценка таких показателей, как успешность фирмы, имидж, любовь потребителя, качество сотрудника также относятся к измерениям. В настоящей работе мы также придерживаемся точки зрения вышеуказанных авторов.
В работе Б.Андерсена также представлена классификация видов измерений:
1) прямые и косвенные (прямые измерения, которые можно измерить инструментально; косвенные, которые можно измерить на основе индикаторов, например индекс удовлетворенности);
Для того чтобы измерить качество воздуха в зале заседаний можно измерить температуру, влажность - это прямые меры, однако достаточно сложно установить их оптимальное соотношение. В этом случае можно измерить число лиц, активно участвующих в обсуждениях или число лиц, по разным причинам покинувших зал. Такие измерения дадут косвенную интерпретацию качества искусственного климата в зале.
2) финансовые и нефинансовые
Финансовые показатели используются наиболее часто. Однако нефинансовые показатели иногда могут дать больше оперативной информации, которая в конечном итоге отразится и на финансовых показателях. Поэтому необходимо совместное использование таких показателей.
3) меры результата и меры процесса
Показатели процесса имеют сильное влияние на результат, и было бы неправильно судить об успешности, только по результату. Поскольку низкий уровень брака на выходе может быть вызван высокими затратами на 100% контроль.
Меры, определяемые в соответствии с целью:
- - меры результата (дают представление о том, что удалось достигнуть, не говоря о том, как это было достигнуто);
- - диагностические меры (это косвенные меры достигнутого, позволяют прогнозировать показатели результата на ближайшую перспективу, их использование дает возможность вовремя определить проблемные места и выбрать способ совершенствования процесса);
- - меры компетенции (определяет способность в целом в дальнейшем достигать запланированных результатов).
Для достижения наибольшей информативности и результативности измерений, применяемые прямые и косвенные, финансовые и нефинансовые показатели, показатели результата и показатели процесса, должны быть сбалансированными. При этом не всегда от измерений требуется предельная точность. Чаще нужно узнать общую тенденцию, достигнуто улучшение или нет, как повлияло принятое решение на показатели. Поэтому здесь важное значение имеет практическая пригодность измерений . Э.Деминг отмечал, что «Функционирование любого составляющего систему подпроцесса должно оцениваться в терминах его вклада в цели всей системы, а не по его индивидуальной производительности или прибыли и ни по какому другому соревновательному критерию»
К.М.Рахлин в работе высказывал мысль об установлении критериев измеримости, исходя из особенностей процессов. Об этом же упоминает и В.В.Ященко , указывая, что очень часто в определении уровня достигнутого значения показателя используются понятия «удовлетворительно», «достаточный», «соответствующий», которые разными людьми могут быть по-своему интерпретированы. Операциональные определения же позволяют всегда понимать друг друга однозначно. Особенно это важно при проведении измерений и сборе данных. Понятие операционального определения ввел Э.Деминг. Подразумевается, что слова и понятия в разных ситуациях могут иметь разный смысл. Например, стол «чистый» означает, что за ним можно обедать или на нем можно проводить хирургические операции. Операциональное определение придает точный смысл слову, исключая двоякость понимания посредством установления того, как понятие измеряется и применяется в конкретном наборе обстоятельств. Для начала работ по измерению и анализу показателей (характеристик) команде необходимо согласовать и в дальнейшем использовать операциональные определения внутри команды. В дальнейшем это позволит избежать ошибок из-за непонимания, которые ведут к потере времени и увеличению вариабельности процесса. Кроме того, необходимо быть осторожными и разумно выбирать количество показателей для измерений. Когда измерений слишком много, появляется избыточная информация, которую невозможно проанализировать. Вследствие этого появляется пренебрежение к информации, и некоторая действительно важная информация может быть пропущена.
Анализируя классификации методов измерений, применяемых в науке о количественной оценке качества - квалиметрии, нами определено, что для измерения и оценивания результатов процессов и продукции системы качества вуза могут применяться следующие методы:
- измерительный - основан на информации, получаемой с использованием технических средств (например, измерение температуры в аудитории, уровня излучения от ПЭВМ и т.д.). Как уже отмечалось, этот метод используется для измерения и оценивания системы качества вуза достаточно редко;
- регистрационный - основан на информации, получаемой путем подсчета числа определенных предметов, событий или затрат (например, число срывов учебных занятий, количество учебных пособий и т.п.);
- расчетный - основан на информации, получаемой с помощью теоретических и эмпирических зависимостей, например, процент охвата социологическими опросами;
- экспертный метод - проводится группой специалистов, например, оценка соответствия программы учебной дисциплины требованиям федерального государственного образовательного стандарта;
- социологический - проводится методом опросов, например, внутренних и внешних потребителей.
Одной из важнейших задач, стоящих перед разработчиками системы качества в соответствии с требованиями ГОСТ Р ИСО 9001-2008, то есть создание системы «как надо», является создание системы показателей качества вуза, необходимой для управления его деятельностью. Но известно, что в результате многолетней деятельности вузов, в каждом из них сложились свои системы качества (системы управления) «как есть», во многом имеющие общие черты. Каждый вуз, создавая свою систему управления, разрабатывал также и систему показателей для ее измерения. Как правило, ежегодный анализ этих показателей, проводимый в вузе, основывается на измерении (оценке) работы по направлениям деятельности: учебно-воспитательная, научная, методическая и другие. Это перекликается с основными процессами его системы качества. Хотя в реестре процессов СибГТУ (таблица 2.5) мы видим несколько другие их наименования: «Реализация основных образовательных программ», «Воспитательная и внеучебная работа с обучаемыми», «Научные исследования и разработки», «Проектирование основных образовательных программ». В вузе собираются сведения, и осуществляется измерение показателей по направлениям деятельности, которые частично «перекрывают» некоторые процессы системы качества. Эти показатели затем сравниваются с показателями стратегического (и ежегодного) планирования вуза, показателями лицензирования и государственной аккредитации, критериями отбора ведущих вузов России и другими. Особое внимание уделяется динамичному развитию вуза. Следовательно, можно утверждать, что при измерении деятельности вуза, в первом приближении, используется процессный подход, в части измерения качества некоторых процессов (аналогов видов деятельности). Но, кроме измерения показателей по направлениям деятельности, в некоторых вузах определяется рейтинг факультета, кафедры, руководителей, преподавателей. То есть в данном случае можно говорить о применении функционального подхода.
Все это можно использовать при формировании системы качества вуза в соответствии с требованиями ГОСТ Р ИСО 9001-2008. В.Г. Елиферов и В.В. Репин также считают, что если в организации существует система показателей деятельности, то необходимо провести декомпозицию этих показателей в показатели процессов. То есть показатели процесса должны быть интегрированы в общую систему показателей деятельности организации (которая достаточно часто применяется в вузах). Это должно привести к интеграции уже существующей и требуемой систем показателей измерения.
- однозначная связь со стратегическими показателями организации (увязка с верхним уровнем);
- «прозрачность» для руководителей организации;
- удобство для владельцев процессов, управляющих своими процессами на основе этих показателей;
- понятность персоналу, выполняющему процесс;
- измеримость (показатели должны быть измеримы в цифровом выражении).
Разрабатываемая система показателей измерения должна являться, прежде всего, инструментом управления для высшего руководства вуза, для которого основными целями измерения является оценка:
- деятельности вуза в целом (динамика развития, сравнение с показателями государственной аккредитации, критерии ведущих вузов России и другие);
- отдельных процессов вуза, работы его конкретных подразделений;
- работы каждого руководителя;
- работы каждого преподавателя и сотрудника.
По нашему мнению, создание системы показателей вуза, также как и определение измеримых целей в области качества вуза и его структурных подразделений (рисунок 3.4), должно происходить по «вертикали» и по «горизонтали». То есть, когда (как было показано в п.3.2), стратегические цели вуза «по вертикали» декомпозируются на структурные подразделения, то в стратегии для каждой стратегической задачи уже определены «измеряемое значение для показателя стратегической задачи» и «величина индикатора достижения стратегической задачи» (таблица 3.6), и их можно использовать для создания системы показателей измерения вуза и его структурных подразделений. В дополнении к ним из информационных карт процессов также можно выделить показатели измерения, полученные по «горизонтали», на основании процессного подхода.
В работе М. Коуэна рассматривается функциональнопроцессная матрица Пола Хэриона, в которой по горизонтали представлено управление по процессам, а по вертикали управление по функциям. Основываясь на этой работе, мы также решили использовать матрицу как инструмент для интеграции различных показателей качества вуза и формирования их в единую систему.
Принимаем, что большинство показателей оценки деятельности вуза можно разделить на три множества:
- 1) Множество А, объединяющее показатели, определенные на основании стратегии вуза;
- 2) Множество В, включающее показатели, полученные из информационных карт процессов;
- 3) Множество С, состоящее из федеральных государственных требований (лицензионных и аккредитационных показателей) и требований ФГОС ВПО.
Все эти три множества являются пересекающимися, то есть некоторые из этих показателей могут входить в два и/или три множества.
Поэтапно показатели множеств А, В и С мы объединяем в подмножества к>п, которые располагаем в блочную матрицу (таблица 3.8). Матрица состоит из трех блоков, расположенных вертикально и соот-
ветствующих различным уровням управления вуза: верхнего (В), среднего (С), нижнего (Н). В каждом блоке есть некоторое число руководителей (от 1 до п), например, для высшего уровня управления эти руководители обозначены Х Ь Х 2 ......Х„. В левой части матрицы представлены процессы: процесс 1, процесс 2......процесс N. Это могут быть ос
новные процессы и/или обеспечивающие. Следовательно, индексы в подмножествах П >, т, к, п означают: верхний - указывает к какому процессу относится подмножество; нижний - порядковый номер руководителя и к какому уровню управления он относится. Например, подмножество П 2 кс означает, что оно относится к процессу 2 и к-ому руководителю среднего уровня управления.
Таблица 3.8
Матрица распределении показателей но процессам и ответственным
руководителям
Процессы |
Уровни управления вуза и ответственные руководители |
||||||||
Высший (В) |
Средний (С) |
Нижний (Н) |
|||||||
х, |
Х„ |
у, |
у к |
||||||
Процесс 1 |
|||||||||
Процесс 2 |
|||||||||
Процесс N |
Для каждой ячейки матрицы проводится анализ с целью исключения дублирования показателей и получения непересекающихся подмножеств П 1 " 1 п1?к, п . Причем часть этих подмножеств для какого-то процесса и руководителя будет «пустой», то есть не будет содержать никаких показателей.
На примере СибГТУ рассмотрим это для двух основных процессов и двух руководителей:
- подмножество П’пв, относящееся к процессу 1 и к п-ному руководителю блока высшего руководства;
- подмножество П 2 1 С, относящееся к процессу 2 и к первому руководителю блока среднего руководства.
Предположим, что к подмножеству п’ пв можно отнести процесс «Проектирование и разработка основной образовательной программы ООП». Это сквозной процесс, в котором участвуют различные структурные подразделения и его управление осуществляется на различных уровнях: вуза, факультетов и кафедр. К подмножеству П 2)с - процесс «Довузовская подготовка», который является функциональным и, в основном, осуществляется силами деканата довузовской подготовки.
На основании стратегии СибГТУ была осуществлена декомпозиция стратегических задач на процессы системы качества вуза (таблица 3.9).
Из информационных карт анализируемых процессов СибГТУ было проведено распределение показателей цели процессов между ответственными руководителями (таблица 3.10).
Декомпозиция показателей стратегических задач на процессы системы качества вуза (фрагмент)
Таблица 3.9
Процессы |
Измеряемые значения показателей стратегических задач |
Ответ ственные |
Проектирование и разработка образовательных программ |
А 1.1.2 Количество рабочих учебных планов по ФГОС ВПО в вузе А 1.4.1 Количество новых конкурентоспособных ООП в вузе А 1.4.2 Количество новых направлений подготовки магистров |
Проректор по учебной работе |
А1.1.2 Количество рабочих учебных планов по ФГОС ВПО на факультете А 1.4.1 Количество новых конкурентоспособных ООП на факультете |
||
А1.1.2 Количество рабочих учебных планов по ФГОС ВПО на кафедре |
Зав. кафедрами |
|
Довузовская подготовка |
А2.2.1 Количество направлений подготовки школьников по элективным курсам А2.2.2 Количество проведенных профориентационных мероприятий А2.2.2 Количество участников профориентационных мероприятий | |
А2.2.1 Процент поступивших в СибГТУ от общего числа обучавшихся на ФДП и подавших заявление на поступление, % |
Для формирования подмножеств П 1 , П 2 ]с для каждой ячейки, относящейся к конкретному процессу и руководителю, объединили показатели: «измеряемые значения показателей и стратегических задач» из таблицы 3.9 и «измеряемые значения показателей цели процесса» из таблицы 3.10. Следует обратить внимание, что при разработке стратегии СибГТУ и создании информационных карт процессов использовались федеральные государственные требования и требования ФГОС ВПО, но рекомендуем еще раз проверить, нельзя ли эти требования и соответствующие им показатели применить к формируемым подмножествам П" пв, П 2 1с , для исследуемых процессов и соответствующих руководителей. Следовательно, должна появиться новая таблица, в которой эти показатели объединены. В монографии она не приводится.
Далее проводится экспертная оценка каждой ячейки новой таблицы, то есть собранных в ней показателей для каждого исследуемого подмножества - П" пв, П 2 1с , с целью исключения коррелируемых или дублирующих показателей. Рекомендуется также исключать показатели, ориентированные на процесс, а не на его результат. Например, показатель «количество проведенных профориентационных мероприятий» для процесса «Довузовская подготовка».
Таблица ЗЛО
Распределение показателей цели процесса между ответственными
руководителями (фрагмент)
Процессы |
Измеряемые значения для показателей цели процесса |
Ответствен |
Проектирование и разработка образовательных про |
Соответствие УМКД/ЭУМКД ООП вуза нормативным требованиям и требованиям заинтересованных сторон Процент обеспеченности УМКК/ЭУМКД ООП вуза Удовлетворенность студентов обеспечением (доступностью) УМКД/ЭУМКД ООП вуза |
Проректор по учебной работе |
Соответствие УМКД/ЭУМКД ООП факультета нормативным требованиям и требованиям заинтересованных сторон |
||
Соответствие УМКД/ЭУМКД ООП кафедры нормативным требованиям и требованиям заинтересованных сторон |
Зав. кафедрами |
|
Довузовская подготовка |
Процент поступивших в СибГТУ от обучившихся на ФДП Удовлетворенность слушателей обучением на факультете довузовской подготовки (ФДП) |
Декан ФДП |
В результате мы получаем таблицу 3.11, содержащую селективные подмножества показателей. Эти показатели можно отнести к ключевым показателям деятельности (КПД). Известно (ГОСТ Р ИСО 9004-2010, п.8.3.2), что «эти показатели должны поддаваться количественному измерению и должны давать возможность организации устанавливать измеримые цели, идентифицировать, вести мониторинг и прогнозировать тенденции и осуществлять корректирующие и предупреждающие действия и действия по улучшению в случае необходимости».
Следует подчеркнуть, что окончательный перечень КПД должен быть подвергнут экспертизе и согласованию со всеми заинтересованными сторонами. В результате в него войдет оптимальный набор КПД,
которые вуз выберет для себя в качестве «универсальной линейки», с помощью которой будут формироваться цели организации, а затем, по истечении определенного временного периода, осуществляется оценка (измерение) их достижения. Это даст возможность рассчитать результативность процессов, дать оценку деятельности руководителей. Кроме того, по мере необходимости, эти показатели можно использовать для мониторинга процессов. Значение этих показателей должно подвергаться анализу с помощью статистических методов управления качеством.
Ключевые показатели деятельности вуза, распределенные по процессам и ответственным руководителям (фрагмент)
Таблица 3.11
Ключевые показатели деятельности вуза |
Ответ ственные |
Процесс «Проектирование и разработка ООП» |
|
|
Проректор по учебной работе |
Процесс «Довузовская подготовка» |
|
|
Разработанная система ключевых показателей деятельности (КПД) вуза (таблица 3.11) не исключает сбор и других показателей или сведений, характеризующих процессы и деятельность вуза по всем направлениям. Это, как правило, мы видим в традиционных годовых отчетах образовательных организаций. В них освещается, что было сделано, сколько и каких мероприятий проведено, достижения вуза и т.д. В работе А.А.Факторович обоснована методология и технология ценностно-мотивационного управ-
ления качеством педагогической деятельности преподавателя вуза. Ценностно-мотивационный подход в управлении качеством образовательного процесса в вузе не отменяет процессный, но расширяет его возможности. Представлены основные показатели и критерии эффективности внутриву-зовской системы управления качеством образования, построенной в соответствии с ценностно-мотивационным подходом. На наш взгляд, эти показатели и критерии могут также быть использованы при формировании системы ключевых показателей деятельности вуза.
Разработанная система ключевых показателей деятельности образовательной организации позволит:
- исключить дублирование показателей;
- более четко распределить ответственность между руководителями различного ранга;
- повысить управляемость процессов системы качества образовательной организации.
На наш взгляд, система КПД позволит провести оценку качества системы управления, по принципу: цели были поставлены, и как (насколько) они были реализованы. Это будет продвигать вузы к переходу реализации их деятельности на основе принципов менеджмента качества.
На рисунке 5 изображена пошаговая схема разработки системы показателей в организации.
Предполагается, что у организации уже существует четко определенная система стратегических целей верхнего уровня и стратегия. В этом случае задача построения системы показателей существенно упрощается. Если же стратегия и цели не сформулированы, разработать адекватную систему показателей сложнее.
Прежде всего (шаг 1 ) необходимо определить цели разработки системы показателей. Для чего она будет использоваться? Возможные варианты ответов представлены ниже:
Для контроля реализации стратегии и достижения стратегических целей компании;
Для контроля операционной эффективности и улучшения процессов;
Для формирования отчетности для собственников;
Для разработки системы мотивации персонала.
В зависимости от целей разработки система показателей будет иметь различную сложность. Если, например, у организации нет четко определенной стратегии, то акцент при разработке системы может быть сделан на показатели операционной эффективности.
Если стратегия у организации есть, то на шаге 2 необходимо разработать конкретные показатели достижения стратегических целей. Степень конкретности должна быть такой, чтобы было понятно, кто из менеджеров отвечает за достижение по каждому показателю установленных целевых значений. Одновременно может выполняться шаг 3 , связанный с разработкой (точнее, с пересмотром уже существующих) индикативных показателей уровня организации в целом. Таких показателей в системе должно быть немного. Лучше сосредоточить внимание на конкретных показателях.
Рисунок 5 – Методика разработки системы показателей организации
На шаге 4 на основе конкретных показателей достижения стратегических целей разрабатываются показатели оценки операционной эффективности процессов (для одного и более уровней). Желательно при этом обратить внимание на сквозные процессы и разработать соответствующие показатели. Часть показателей достижения стратегических целей может быть напрямую (без детализации) отнесена к соответствующим процессам.
На шаге 5 необходимо свести все разработанные показатели в единую систему, оформить ее документально и провести серию согласований на различных уровнях управления. Желательно привлечь к этой работе собственников, поскольку менеджмент может быть заинтересован в создании адекватной системы показателей.
При сведении всех показателей в единую систему может оказаться, что некоторые из них излишни по различным причинам (взаимное дублирование, невозможность расчета, низкая информативность и т. п.). Такие показатели исключаются из системы.
Шаг 6 включает в себя необходимость разработать методики расчета для показателей, вошедших в систему. Методика расчета должна содержать все необходимые требования для обеспечения расчета показателя, например, перечень исходных данных и их источники, формулу расчета, его периодичность, ответственных за расчет и т. д.
При разработке методик расчета показателей часто оказывается, что для части из них невозможно получить исходные данные, для других формула расчета является слишком сложной или спорной и т.п. Может выясниться, что ряд показателей дублируется. Поэтому в ходе разработки методик система показателей может измениться.
После того как созданы система показателей и методики их расчета, необходимо разработать формы управленческой отчетности (шаг 7 ). Проще всего их сделать с помощью MS Excel. Поскольку методики расчета содержат формулы для расчета, то последние могут быть использованы при настройке отчетов в Excel.
На завершающем этапе (когда и система показателей, и методики их расчета, и формы отчетности разработаны) они утверждаются и запускаются в работу (шаг 8 ).
После двух-трех циклов планирования и отчетности система показателей, методики расчета и разработанные формы отчетности должны быть скорректированы с учетом опыта их практического использования в организации.
Даже если стратегия компании представляется совершенно ясной ее руководителю, этого недостаточно для того, чтобы она успешно выполнялась. стратегия должна быть понятна всем членам управленческой команды и сотрудникам, необходимы средства управления реализацией стратегии, позволяющие направлять и отслеживать траекторию движения фирмы к ее стратегическим целям. Статья посвящена методике построения сбалансированной системы показателей, которая является инструментом стратегического управления компанией.
Сбалансированной системе показателей (ССП) посвящено немало статей и книг. Однако часто те, кто хочет разобраться в этой методологии, испытывают разочарование даже после прочтения значительного количества публикаций на данную тему. Остается неясным, с чего следует начать и в какой последовательности действовать, чтобы построить работающую ССП. Данная статья является попыткой преодоления этой проблемы. В ней изложена пошаговая методика разработки ССП, хорошо отработанная на многих проектах.
В предыдущей статье автора “Разработка стратегии – первый шаг к ССП” подчеркивалась необходимость ясного определения стратегии до начала работы по созданию сбалансированной системы показателей. Действительно, прежде чем заниматься разработкой формализованной системы управления стратегией, которой является ССП, необходимо уделить особое внимание созданию самой стратегии и четкому определению ее основных положений. Только на этой прочной основе можно построить здание сбалансированной системы показателей. в настоящей статье мы будем исходить из того, что такой фундамент создан.
В качестве иллюстрации излагаемой методологии продолжим начатое в предыдущей статье рассмотрение примера разработки ССП генподрядной строительной компанией “Монолит” из Екатеринбурга. В основе этого примера лежит проект, в котором авторы выступали в качестве консультантов. Материалы проекта адаптированы для целей публикации; изменены название и местонахождение компании.
Организация проекта
Первый этап разработки ССП организационный. Нужно определить состав команды проекта, составить план работы, установить сроки, назначить ответственных исполнителей. Каждая стадия проекта должна принести конкретные результаты. Не завершив один этап, нельзя переходить к следующему.
Команда проекта – это люди, относящиеся к стратегическому уровню руководства компании, те, кто отвечает за определенные направления стратегии. В компании “Монолит” в команду проекта вошли:
- генеральный директор;
- заместитель генерального директора по производству;
- директор по маркетингу;
- директор по персоналу;
- финансовый директор;
- пять директоров проектов, каждый из которых руководит строительством группы объектов определенного типа (торговые центры, офисные помещения, производственные предприятия и др.).
Оптимальная численность команды – семь-десять человек. При большем числе участников сложнее организовать коллективную работу. Кроме того, в средней компании не должно быть большого количества стратегов. В крупной организации в разработке стратегии участвует значительно большее число людей, поэтому создаются несколько команд в соответствии с управленческой иерархией.
Необходимо подчеркнуть, что разработка ССП – это коллективная работа. Если ее выполнит один человек, например генеральный директор, то результат не будет иметь никакой ценности.
После того как команда сформирована, необходимо назначить руководителя проекта, администратора и архитектора системы. Руководитель отвечает за результаты проекта, имеет в своем распоряжении все необходимые ресурсы для его выполнения, принимает все ключевые решения в ходе проекта. Обычно руководитель такого проекта – это первое лицо компании.
Администратор проекта выполняет технические управленческие функции: информирование членов команды, обеспечение коммуникаций, ведение документации, контроль исполнения принятых решений и др.
Архитектором системы необходимо выбрать такого члена команды, который лучше других знаком с методологией ССП, обладает аналитическими способностями, умеет управлять дискуссией. Архитектор направляет усилия команды на протяжении всего проекта, формулирует вопросы для обсуждения, оформляет результаты каждого этапа.
В компании “Монолит” руководителем проекта стал генеральный директор, администратором – директор по персоналу. Выполнять функции архитектора было поручено консультантам.
В тех случаях, когда компания разрабатывает ССП без участия консультантов, необходимо провести предварительное обучение специалиста, который выдвигается на роль архитектора. Этот сотрудник должен изучить литературу по данной теме и посетить тренинги, на которых вырабатываются практические навыки, требующиеся для решения подобных задач. Как показывает опыт различных компаний, архитектором системы нередко становится директор по персоналу, директор по маркетингу или финансовый директор.
После того как команда проекта сформирована и ключевые роли определены, нужно обсудить и зафиксировать цели проекта. Это важно по следующим причинам:
- все участники проекта должны осознавать, к чему стремится команда, и это понимание должно быть единым;
- необходимо установить критерии успеха проекта, по которым в дальнейшем можно судить, осуществилось ли то, что планировалось сделать.
Члены команды проекта компании “Монолит” поставили следующие цели:
- представить стратегию в виде, понятном всем сотрудникам компании;
- четко разделить ответственность за выполнение стратегии между участниками вплоть до исполнителей;
- создать механизм стратегического контроллинга, позволяющий отслеживать выполнение стратегии.
Когда цели зафиксированы, следует приступить к разработке плана проекта. Проекты данного типа обычно включают следующие этапы:
- разработка стратегических целей;
- составление карты стратегии;
- создание показателей;
- установление целевых значений показателей;
- разработка стратегических мероприятий;
- внедрение ССП.
На организационном этапе необходимо также определить график работы команды – установить дни, в которые она будет собираться для коллективной работы. Оптимальный вариант – проведение рабочих сессий продолжительностью четыре часа один раз в две недели. Уплотнить график обычно не получается по причине высокой занятости руководителей. Однако длительные паузы между сессиями приводят к потере энергии, растягиванию сроков проекта. Необходимо учитывать, что между сессиями идет активное выполнение домашних заданий, которые получает каждый участник проектной команды.
Разработка стратегических целей
Первая задача, которую должна решить проектная команда, – это определение стратегических целей для включения в ССП. Цели обычно группируются по четырем проекциям:
- финансы;
- рынок;
- процессы;
- потенциал.
Число проекций и их названия не предписываются методологией ССП. Смысл группировки стратегических целей в разрезе проекций состоит в том, чтобы выделить все стратегически важные аспекты деятельности компании и в каждом из них установить цели. Так, проекция “Финансы” отражает интересы акционеров и содержит наиболее значимые для них цели, связанные с ростом финансовых показателей деятельности компании. Проекция “Рынок” включает цели, касающиеся повышения удовлетворенности и лояльности клиентов, увеличения клиентской базы, объемов продаж и доли рынка. Очевидно, финансовых цели можно добиться лишь при условии достижения успехов на рынке. К проекции “Процессы” относятся цели совершенствования процессов и структур компании, за счет которых достигаются успехи в работе с клиентами и завоевании рынка. Проекция “Потенциал” имеет много альтернативных названий, однако обобщенно можно сказать, что в ней сосредоточены цели компании, связанные с развитием ее ключевых ресурсов, к которым относятся прежде всего люди. В эту же проекцию нередко включаются информационные технологии как ключевой информационный ресурс современного бизнеса. Цели данной проекции обеспечивают базу достижения успеха по всем остальным направлениям.
Определяя заранее состав проекций, мы тем самым стараемся подстраховаться от того, чтобы не упустить из поля зрения какие-либо важные стороны стратегии, поэтому подходить к выбору состава проекций нужно творчески. Нередко число проекций достигает пяти или шести главным образом за счет уточнения аспектов деятельности компании на рынке (например, может появиться проекция “Поставщики”) или детализации проекции “Потенциал” (в частности, можно выделить “Персонал” и “Информационные системы”). Нужно заметить, что увеличение числа проекций до семи и более нежелательно, поскольку это может привести к дроблению целостного стратегического видения на частные задачи.
Решив вопрос, касающийся количества проекций и их названий, можно приступать к задаче разработки целей. Исходными данными для ее решения является определение стратегии, выработанное до начала этого проекта. Каждый член команды должен предложить формулировки нескольких стратегических целей для каждой проекции. Целесообразно организовать эту работу следующим образом.
- на собрании членов команды архитектор системы объясняет участникам, как нужно формулировать цели, в каком виде представлять результаты.
- Получив домашнее задание, члены команды готовят свои предложения и передают их администратору проекта.
- Администратор подготавливает материалы для групповой работы, записывая формулировки целей крупными буквами на карточки, которые помещаются на стены аудитории.
- Команда проекта собирается для проведения мозгового штурма на тему “Определение стратегических целей компании”. Работа начинается с ознакомления с результатами домашней работы, представленными в виде каточек, которые должны быть сгруппированы по проекциям. Участники рабочей сессии, изучив представленные материалы, вносят свои дополнения и уточнения. На этом этапе не должно быть критических замечаний, однако допускаются вопросы, цель которых – уточнить смысл формулировок целей. Результатом совместной работы должен стать максимально широкий набор целей, сгруппированных по проекциям. При этом необходимо, чтобы члены команды одинаково понимали, что кроется за формулировками, зафиксированными на карточках. Сокращение числа карточек на данном этапе допускается только в случаях дублирования записанных на них определений. Таким образом, создается основа для дальнейшей работы по отбору и уточнению стратегических целей.
Для получения хороших результатов на этом этапе важно, чтобы члены проектной команды руководствовались правилами формулирования целей.
- Цель должна представляться в виде глагола, стоящего в повелительном наклонении, с зависимым словом, например “достичь результата”, “улучшить показатели”, “снизить издержки”.
- Цель должна иметь стратегическое значение, т.е. не быть слишком “приземленной”, соответствующей уровню мероприятия. Например, формулировка “Обеспечить грузчиков склада спецодеждой” не соответствует масштабу стратегической цели. Для решения этой задачи нет необходимости выносить ее на стратегический уровень.
- Цель должна быть достаточно конкретной, чтобы сотрудники понимали, какие действия последуют за ее определением. Например, фраза “Улучшить моральный климат в коллективе” является слишком размытой, поэтому ее нельзя рассматривать как стратегическую цель. Это не более чем общее пожелание, не побуждающее к конкретным действиям. Когда появляются подобные формулировки, необходимо задать уточняющий вопрос: “Что именно нас не устраивает в данной ситуации, что мы хотим улучшить”? Причиной неудовлетворительного положения может быть, например демотивирующий стиль руководства менеджеров среднего звена. Тогда цель звучит таким образом: “Создать сильный средний уровень менеджмента”. Понятно, что далее будут предприняты конкретные действия по формированию, обучению и воспитанию менеджеров среднего звена.
Результаты работы проектной команды компании “Монолит”, полученные на этапе генерации стратегических целей, представлены в табл. 1.
Таблица 1. Начальный список целей для ССП
Проекция |
Цели |
11. Создать интернет-портал по тематике управления рисками строительных проектов 12. Подготовить и издать методическое руководство для клиентов по снижению рисков строительных проектов |
|
Процессы |
|
Потенциал |
34. Создать собственный парк строительной техники с целью сокращения объемов субподрядных работ |
Как видно из табл. 1, в ходе мозгового штурма команда сгенерировала 34 стратегические цели. Все они записаны на карточках и сопровождаются номерами для удобства дальнейшей работы с ними. При подготовке материала статьи число целей было сокращено. На самом деле количество таких карточек обычно составляет 50-100. В действительности это неплохой показатель наличия единого видения стратегии в команде. Если на этапе, предшествующем разработке ССП, все члены команды участвовали в формировании стратегии, то в ходе выбора стратегических целей они демонстрируют высокий уровень единения. При этом группа из семи-десяти человек формулирует не более 40»50 целей. Если же обсуждению стратегии не уделялось должного внимания, то разработка ССП “вязнет” в непрерывных дебатах, поскольку разброс мнений по каждому вопросу крайне широк.
Следующим шагом является критическое рассмотрение стратегических целей и отбор из начального списка тех, которые заслуживают включения в ССП. Это делается в ходе командной работы. Последовательно рассматривается каждая цель списка. При этом участники обсуждения высказывают свое мнение о ней, отвечая на следующие вопросы.
- Согласуется ли эта цель со стратегией? Если да, то каким именно положениям стратегии она соответствует?
- Достаточно ли конкретно определена данная цель, не нужно ли ее сформулировать более точно?
- Не является ли эта цель слишком “мелкой”? Не следует ли отнести ее к мероприятиям?
Модератор дискуссии (обычно в этой роли выступает архитектор системы) дает возможность высказаться каждому участнику, затем резюмирует их мнения, выделяя противоположные точки зрения и сводя вместе сходные позиции. Важным моментом в этом процессе является принятие решения о том, какие цели нужно исключить, а какие оставить. Желательно приходить к решениям, которые поддерживаются всеми участниками, без нажима на них. Авторитарное давление, от кого бы оно ни исходило, разрушает командную работу, и она теряет всякий смысл. Тем не менее компромиссы в данном случае тоже неуместны, поскольку они ухудшают конечный результат. В связи с этим в ситуациях, когда аргументация оппонентов исчерпана и стороны не могут прийти к согласию, лучше всего принять решение о сохранении обсуждаемой цели в списке. На следующих этапах работы эта проблема может решиться сама собой.
Нередко при обсуждении формулировок целей некоторые участники высказывают сомнения относительно возможности измерения соответствующего показателя. Таким образом, возникает вопрос целесообразности включения обсуждаемой цели в ССП. Подобная аргументация вообще не должна рассматриваться на данном этапе. Когда дойдет очередь до разработки показателей, этот вопрос будет решен. Практика показывает, что для любой качественной цели можно разработать измеримый показатель. В формулировку цели не стоит включать числовые величины. Главное требование к определению цели следующее: она должна представлять собой конкретное словесное выражение устремлений компании. Необходимо, чтобы смысловая нагрузка была как можно более емкой. Количественные характеристики будут включены в это определение позже.
Таким образом, после общего обсуждения и выработки решений первоначальный список целей должен быть разделен на три части.
- Цели, предназначенные для включения в ССП. Они распределены на группы, соответствующие выбранным проекциям.
- Цели, не соответствующие стратегии компании. Они исключаются из дальнейшего рассмотрения. При этом их можно разделить на две группы: одни являются непродуктивными, о них нужно забыть, другие содержат правильные инициативы, для реализации которых не требуется включения в ССП, а достаточно поставить задачу руководителям соответствующих подразделений. Например, обеспечение рабочих спецодеждой можно поручить руководителю отдела снабжения, предусмотрев соответствующие расходы в бюджете. В данном случае речь идет о целях функционального уровня, не имеющих стратегического масштаба.
- Цели низкого уровня – это задачи, которые следует отнести к мероприятиям, обеспечивающим достижение стратегических целей. Они вписываются в стратегию компании, но должны входить в план работ по реализации стратегии, который будет разрабатываться позднее.
Проектная команда компании “Монолит” после критического рассмотрения перечня целей сформировала три списка:
- список целей, которые должны войти в сбалансированную систему показателей (табл. 2);
- список целей, не включенных в ССП (табл. 3);
- список стратегических мероприятий, не включенных в число целей ССП (табл. 4).
Как видно из табл. 2, в число целей ССП вошли 17 целей из первоначального списка. Это хороший результат. Необходимо стремиться к тому, чтобы количество целей в ССП было близко к 20: 15 целей мало, а 25 – уже много.
Таблица 2. Список целей, включенных ССП
Проекция |
Цели |
3. Увеличить прибыльность компании 4. Снизить затраты на устранение брака и простои |
|
7. Создать уникальное рыночное позиционирование 8. Повысить эффективность управления отношениями с заказчикам 9. Увеличить стоимость услуг генподряда 10. Повысить лояльность клиентов 15. Увеличить приток целевых клиентов 16. Построить долгосрочные отношения с субподрядчиками |
|
Процессы |
19. Повысить эффективность процесса продажи проектов 20. Сократить простои в ходе проектов 21. Внедрить методы управления рисками строительных проектов 24. Повысить эффективность маркетинговых коммуникаций |
Потенциал |
25. Повысить профессиональный уровень руководителей проектов в сфере управления рисками 26. Создать эффективное информационное обеспечение процессов управления отношениями с клиентами 27. Обеспечить высокую мотивацию участников процесса продаж 31. Повысить квалификацию директоров проектов в сферах продаж и коммуникаций 32. Создать систему профессионального обучения и наставничества |
Таблица 3. Список целей, не включенных ССП
Проекция |
Цели |
1. Повысить оборачиваемость капитала 2. Снизить управленческие расходы |
|
5. Расширить набор услуг, предлагаемых заказчикам |
|
Процессы |
17. Сократить сроки подготовки тендерной документации 18. Увеличить число проектов, выполняемых компанией |
Потенциал |
28. Внедрить автоматизированную систему для подготовки строительных смет 30. Снизить производственные затраты за счет привлечения работников из регионов 34.Создать собственный парк строительной техники с целью сокращения объемов субподрядных работ |
Таблица 4. Список задач, отнесенных к стратегическим мероприятиям
Проекция |
Цели |
6. Создать ассоциацию субподрядчиков для координации действий по повышению качества услуг |
|
11. Создать интернет-портал по тематике управления рисками строительных проектов 12. Подготовить и издать методическое руководство для клиентов по снижению рисков строительных проектов 13. Разработать план маркетинга на основе нового позиционирования компании 14. Проводить регулярные опросы с целью выявления степени удовлетворенности клиентов |
|
Процессы |
22. Разработать и внедрить регламент процесса продаж 23. Создать базу данных субподрядчиков для снижения рисков выбора исполнителей работ в проектах |
Потенциал |
29. Провести оценку профессионального уровня сотрудников 33. Внедрить автоматизированную систему CRM для поддержки процессов управления отношениями с клиентами |
Ограничение числа целей в ССП является принципиально важным требованием. Нельзя забывать, что мы занимаемся описанием стратегии, которая отражает самые важные направления развития компании. Если в ССП содержится большое количество целей, это означает, что у руководителей компании нет ясности относительно приоритетов и фактически отсутствует стратегия.
Слишком малое число целей в ССП может говорить о недостаточной конкретизации, чрезмерном обобщении формулировок.
Чем руководствовались члены команды “Монолит”, исключив из дальнейшего рассмотрения такие цели, как снижение управленческих расходов (2), расширение набора услуг, предлагаемых заказчикам (5) и другие, оказавшиеся в табл. 3? Основной критерий – это несоответствие стратегии компании. Контроль управленческих затрат должен всегда находиться поле зрения руководства. Однако это не является тем стратегическим направлением, при реализации которого команда намерена добиться решающего успеха. Если бы проблемой фирмы были непомерные затраты на управление, то, несомненно, эта цель попала бы в число стратегически значимых. Однако при разработке стратегии эта проблема не поднималась, поэтому данная цель была отклонена.
Аналогичная аргументация относится к другим целям, представленным в табл. 3.
На рассматриваемом этапе неизбежно возникает немало споров, поэтому хочется еще раз напомнить о важности тщательной работы по формированию стратегии, которая должна предшествовать созданию ССП. Члены команды, у которой есть единое видение стратегии, легче приходят к согласию при обсуждении соответствующих целей.
В завершение данного этапа работы необходимо документировать цели, включенные в ССП. кроме наименования целей, итоговый документ содержит их развернутые определения, поясняющие смысл формулировок, а также обоснование целей (почему они включены в ССП). Для каждой цели указаны исполнители и координатор, отвечающий за организацию действий, обеспечивающих ее достижение. Пример описания целей приведен в табл. 5.
Тщательное документирование результатов работы команды необходимо, для того чтобы:
- зафиксировать достигнутое командой согласие по определению стратегических целей;
- передать понимание стратегических целей менеджерам среднего звена, которые будут вовлечены в дальнейшую работу по реализации стратегии.
Таблица 5. Пример документирования стратегических целей
Цель |
Перспектива ССП |
Определение цели |
Обоснование цели |
Участники |
Координатор |
|
Снизить затраты на устранение брака и простои |
Достижение предполагает значительное снижение затрат, источниками которых являются переделки по вине исполнителей строительных работ, а также оплата человеческих и иных ресурсов, не используемых по причине простоев |
Достижение этой цели должно обеспечить рост рентабельности и прибыли компании |
Директора проектов |
Финансовый директор |
||
Создать уникальное рыночное позиционирование |
Достижение цели предполагает формирование уникальных отличий компании от конкурентов, понимаемых целевыми клиентами |
Четкое позиционирование является ключом к решению целого ряда проблем компании и должно обеспечить увеличение числа целевых клиентов, повышение стоимости услуг компании, рост прибыли |
Директора проектов |
Директор по маркетингу |
||
Внедрить методы управления рисками строительных проектов |
Процессы |
Достижение цели предполагает внедрение методов и технологий проектного менеджмента с ориентацией на снижение рисков на всех уровнях управления компанией |
Применение методов и технологий проектного менеджмента должно обеспечить улучшение качества работ, соблюдение сроков, повышение удовлетворенности заказчиков |
Директора проектов |
Заместитель генерального директора по производству |
|
Повысить квалификацию директоров проектов в области продаж и коммуникаций |
Потенциал |
Достижение цели предполагает овладение директорами проектов навыками продаж и эффективных коммуникаций с клиентами |
Директора проектов играют ведущую роль в процессе продаж. Повышение их квалификации в данной области должно обеспечить результативность продаж и рост числа договоров, заключенных с целевыми клиентами |
Директора проектов |
Директор по маркетингу |
Разработка карты стратегии
Карта стратегии отражает стратегические цели и взаимосвязи между ними. Создатели методологии Balanced Scorecard Д. Нортон и Р. Каплан дали новое определение корпоративной стратегии как цепочке причинно-следственных связей. В соответствии с этим карта стратегии наглядно представляет стратегию компании.
Карта стратегии разрабатывается с участием всей команды. Карточки с целями размещаются на доске с помощью клейкой ленты. Наверху располагаются цели проекции “Финансы”, под ними – проекции “Рынок”, еще ниже – проекций “Процессы” и “Потенциал”. Ведущий рабочей сессии выбирает одну из целей проекции “Финансы” и просит участников назвать другие ее цели, достижение которых будет способствовать приближению к первой.
В рассматриваемом примере компании “Монолит” архитектор системы, ведущий дискуссию, выбрал цель “Повысить прибыльность компании» (3) и попросил высказаться участников относительно связанных с ней целей. Члены команды дружно указали на цель “Снизить затраты на устранение брака и простои” (4). По общему мнению, ее достижение будет способствовать повышению прибыли компании. Модератор открепил карточку с целью 4 от доски и поместил ее под целью 3, а затем провел фломастером стрелку от цели 4 к цели 3. Далее он попросил назвать цели проекции “Рынок”, помогающие достичь цели 3. Сначала многие из присутствующих настаивали на том, что каждая цель этой проекции помогает повысить прибыль. Однако после разъяснения ведущего о том, что необходимо выделять прямые, наиболее значимые связи, участники дискуссии сошлись на том, что непосредственное воздействие на прибыль оказывают следующие цели: “Повысить стоимость услуг генподряда” (9) и “Увеличить приток целевых клиентов” (15). Остальные цели этой проекции влияют на прибыль опосредованно. Когда карточки с целями 9 и 15 были перемещены на новые места и соединены стрелками с целью 3, ведущий предложил поработать с проекцией “Процессы”. Нет ли в ней целей, непосредственно связанных с целью 3? Было решено, что на прибыль оказывает влияние цель “Повысить эффективность процесса продажи проектов” (19). В проекции “Потенциал” целей, которые можно связать с целью 3, обнаружено не было.
После этого ведущий выбрал цель 4, и команда последовательно рассмотрела наличие связей между ней и целями, расположенными в других проекциях.
Таким образом, был проведен анализ каждой цели и выявлены все существенные связи. В ходе этой работы карточки перемещались по доске, стрелки между ними прочерчивались, стирались и проводились заново. В конце концов, схема приобрела стройность и законченность, а члены команды получили удовлетворение от хорошо выполненной работы. Стратегия компании получила зримое воплощение (см. рисунок).
Рисунок. Карта стратегии компании
Для получения хороших результатов на этапе разработки карты стратегии полезно руководствоваться несколькими правилами.
- Не стремиться обозначать все сколько-нибудь значимые взаимосвязи между целями. Необходимо выделять только самые существенные связи.
- Не дублировать связи: если существует последовательность связей между целями А и В, а также между В и С, то не нужно соединять стрелкой цели А и С. Это ничего нового не добавляет к логике схемы (А и С и так связаны через В), но перегружает ее, делая более сложной для восприятия.
- Стараться так располагать на схеме цели и связи, чтобы избегать пересечения стрелок. Как правило, это удается, если схема не содержит лишних связей.
Необходимо помнить, что карта стратегии выполняет коммуникативную функцию, т.е. объясняет всем заинтересованным сторонам смысл стратегии компании, поэтому карта должна быть построена так, чтобы создавался ясный и убедительный образ стратегии.
После завершения построения причинно-следственных связей все цели должны быть соединены с другими, при этом от каждой из них должна выстраиваться цепочка, выводящая на самую верхнюю цель, изображенную на схеме. Если для каких-то целей эти правила не соблюдаются, это означает, что данные цели являются “лишними”, соответственно, их следует удалить с карты стратегии или подумать о промежуточных целях, которые должны связать тупиковые ветви схемы с ее вершиной.
Построение карты стратегии является первым результатом в процессе создания ССП, представляющим самостоятельную ценность. Действительно, руководство компании получает мощный коммуникативный инструмент, помогающий членам управленческой команды понять стратегию и объяснить ее акционерам, сотрудникам, партнерам.
Для того чтобы данная карта превратилась в инструмент управления реализацией стратегии, необходимо:
- разработать показатели, с помощью которых можно измерить “расстояние” до целей;
- установить целевые значения показателей;
- разработать комплекс стратегических мероприятий, проектов, обеспечивающих достижение целей;
- внедрить сбалансированную систему показателей, обеспечив регулярное поступление данных для мониторинга целевых показателей, формирование отчетности.
Эти задачи будут рассматриваться во второй части статьи.
480 руб. | 150 грн. | 7,5 долл. ", MOUSEOFF, FGCOLOR, "#FFFFCC",BGCOLOR, "#393939");" onMouseOut="return nd();"> Диссертация - 480 руб., доставка 10 минут , круглосуточно, без выходных и праздников
Рождественская Каринэ Самвеловна. Разработка системы критериев и показателей оценки эффективности инновационных проектов при создании интегрированных систем управления промышленным производством: диссертация... кандидата экономических наук: 08.00.05 / Рождественская Каринэ Самвеловна; [Место защиты: Рос. гос. ун-т инновац. тех. и предп.].- Москва, 2008.- 142 с.: ил. РГБ ОД, 61 08-8/2014
Введение
Глава 1. Анализ структурно - функционального построения ИАИСУ промышленным производством и методов оценки их эффективности 9
1.1. Анализ структурно-функционального построения ИАИСУ в промышленном производстве 9
1.2. Организация создания и реализации ИАИСУ 21
1.3. Анализ методов и подходов оценки эффективности информационных технологий и постановка задач исследования 31
Глава 2. Разработка критериев, системы показателей и механизма оценки эффективности инновационных проектов при создании ИАИСУ с учетом инфляционных процессов 51
2.1. Критерии оценки эффективности инновационных проектов при создании ИАИСУ 51
2.2. Дисконтирование потоков денежных средств на предприятии 54
2.3. Методы оценки эффективности инновационных проектов 57
2.4. Методика определения затрат, связанных с созданием и реализацией инновационных проектов 73
2.5. Факторы и источники образования социально-экономического эффекта 82
2.6. Синергетический эффект от интеграции локальных АИСУ 92
2.7. Учет инфляционных процессов при оценке эффективности инновационных проектов 94
Глава 3. Риски и их учет при финансировании и реализации инновационных проектов при создании ИАИСУ 100
3.1. Системный подход к определению неопределенности и рисков в автоматизированных системах управления 100
3.2. Влияние факторов риска и неопределенности на эффективность инновационных проектов 106
3.3. Метод экспертных оценок 113
3.4. Методы корреляционного анализа и имитационного моделирования.. 124
Заключение 133
Литература 134
Введение к работе
Актуальность исследования. В настоящее время на промышленных предприятиях России, как и во многих экономически развитых странах, в целях повышении эффективности промышленного производства бурно развиваются интегрированные автоматизированные информационные системы управления (ИАИСУ), охватывающие стадии научно-исследовательских работ, проектирования, производства и реализации продукции. Одной из важных задач среди других задач, решаемых на предприятиях, является оценка эффективности инновационных проектов при создании ИАИСУ. Под инновационными проектом понимается план реализации конечного результата интеллектуальной деятельности человека, его идей, открытий, изобретений и рационализации в виде новых или отличных от предшествующих объектов.
ИАИСУ - человеко-машинные системы управления, реализующие комплексы задач на основе единого организационного, информационного, технического, математического и программного обеспечения для достижения поставленных целей.
Разработка критериев, системы показателей и механизма оценки эффективности инновационных проектов при создании таких систем управления позволяет уже на стадии проектирования ИАИСУ осуществить оценку эффективности вкладываемых инвестиций и выбора варианта наиболее оптимального вложения этих инвестиций. Это, в свою очередь, позволяет за минимальные сроки возвратить затраченный капитал, минимизировать необходимые затраты при разработке и реализации ИАИСУ.
Как показывает проведенный анализ существующих методических подходов и методов оценки эффективности информационных технологий, имеющиеся теоретические и методологические разработки в этой области научных исследований, не отражают действительно происходящих процессов отдачи от применения проектов при создании ИАИСУ в промышленном про- изводстве. При проводимых расчетах эффективности практически не учитываются социальные результаты, недостаточно полно отражаются факторы и источники образования социально-экономического эффекта, не учитывается эффект синергизма (взаимодействия локальных АИСУ). В некоторых случаях при проводимых расчетах не учитываются инфляционные процессы и риски, связанные во времени и пространстве с вкладываемыми инвестициями. Таким образом, разработка научно обоснованных критериев и системы показателей оценки эффективности проектов при создании ИАИСУ является задачей весьма актуальной.
Цель и задачи исследования. Целью исследования является разработка научно обоснованных критериев, системы показателей и механизма оценки эффективности инновационных проектов при создании ИАИСУ с учетом инфляционных процессов и рисков.
Для достижения поставленной в диссертационной работе цели решаются следующие задачи: провести анализ структурно-функционального построения ИАИСУ в промышленном производстве и разработать критерии оценки их эффективности; разработать систему показателей и механизм оценки социально-экономической эффективности инновационных проектов при создании ИАИСУ; разработать методику определения затрат, связанных с созданием и реализацией систем управления; определить факторы и источники образования социально-экономического эффекта; разработать подход к определению синергетического эффекта с учетом инфляционных процессов и рисков.
Объект исследования. Объектом исследования являются инновационные проекты при создании ИАИСУ промышленным производством. Предмет исследования. Предметом исследования являются подходы и методы оценки эффективности инновационных проектов, базирующихся на применении информационных технологий.
Теоретические и практические вопросы в области оценки эффективности информационных технологий нашли свое отражение в работах отечественных и зарубежных ученых: Винера Н., Царева В.В., Непомнящего Е.Г., Ви-ленского П.Л., Ковалева В.В., Коссова В.В., Шарпа У.Ф., Бланка И.А., Бром-вича М., Князевой Е.Н., Мыльника В.В., Парамонова Ф.И., Клейнера Г.Б., Скрипкина К.Г., Титоренко Г.А., Дамодарана А., Когаловского P.M., Гитма-на Л.Д., Джонка М.Д., Золотогорова В.Г., Липсица И.В., Беренса В., Хавране-ка П.М., Аныпина В.М., Девераджа С, Кохли Р., Римера М.И., Балдина К.В., Лимитовского М.А., Лившица В.Н., Хакена Г.
Методы исследования. Проведенное исследование базируется на системном подходе к анализу структурно-функционального построения ИАИСУ и методов оценки их эффективности. Для решения поставленных в диссертационной работе задач использовались теоретические, методологические и методические основы построения ИАИСУ, методы экономического анализа, экспертных оценок, системного и ситуационного анализа, экономико-математического моделирования. Теоретической основой исследования являются труды зарубежных и отечественных ученых в области построения ИАИСУ и оценки их эффективности.
Научная новизна. Научная новизна диссертационного исследования состоит в разработке системы критериев и показателей оценки эффективности инновационных проектов при создании интегрированных АИСУ промышленным производством. Наиболее значимыми научными результатами исследования являются: разработаны критерии оценки эффективности инновационных проектов при создании ИАИСУ промышленным производством на основе анализа их структурно-функционального построения; разработана система показателей и механизм оценки эффективности инновационных проектов при создании ИАИСУ во времени и пространстве; разработана методика определения затрат, связанных с созданием и реализацией инновационных проектов при создании ИАИСУ; определены факторы и источники образования социально-экономического эффекта, отражающие реальные процессы применения систем управления; разработан подход к определению синергетического эффекта с учетом инфляционных процессов и рисков.
Практическая значимость. Разработанная система критериев и показателей оценки эффективности инновационных проектов при создании ИАИСУ позволяет уже на стадии проектирования этих систем определять будущую эффективность вкладываемых инвестиций. Это объясняется тем, что все проводимые расчеты затрат и результатов осуществляются с помощью коэффициента дисконтирования, то есть приведением затрат и результатов по фактору времени к первоначальному моменту вложения инвестиций. Результаты исследования представляют научный интерес, а также практическую значимость для промышленных предприятий при создании и реализации ИАИСУ. Материалы диссертации могут быть также использованы в учебных целях в качестве учебных пособий при чтении лекций и дипломном проектировании в ВУЗах.
Апробация работы. Основные положения диссертационной работы реализованы при разработке ИАИСУ наукоемким производством ФГУП «ММПП «Салют». Отдельные разделы диссертации использовались при подготовке курса лекций, методических пособий, курсовых работ по дисципли- нам «Оценка бизнеса», «Финансы и кредит», а также при выполнении дипломных и курсовых работ на экономических кафедрах ряда ВУЗов.
Результаты исследования докладывались на Шестой Международной конференции «Авиация и космонавтика» с 1 по 4 октября 2007 г., Международной молодежной научной конференции «XXXIV Гагаринские чтения» в МАТИ имени К.Э. Циолковского в 2008 г., Международной научно-практической конференции «Менеджмент качества и формирование стратегии развития экономических систем» - СПб, 20-21 апреля 2008 г.
Публикации. По материалам выполненных исследований опубликованы 8 научных работ, общим объемом 5,8 п.л., в том числе 3 научные работы в издательствах, рекомендованных ВАК.
Объем работы. Диссертация состоит из введения, трех глав, заключения, списка литературы. Основные результаты исследования изложены на 142 страницах, 24 рисунках и 11 таблицах. Список литературы содержит 122 наименования.
Организация создания и реализации ИАИСУ
Организация создания и реализации интегрированных автоматизированных информационных систем управления (ИАИСУ) представляет собой комплекс научно-исследовательских, проектных, инженерно-технических и организационных работ, направленных на совершенствование существующей или вновь создаваемой системы управления с применением СВТ, математических и современных методов управления. Совершенствование системы управления означает переход к качественно новой ступени ее развития, изменения организационной структуры управления и принципов ее функционирования. Процесс организации и создания систем управления можно представить в виде инвестиционного проекта. Под инвестиционным проектом (investment project) понимается план или программа вложения инвестиций в систему управления для достижения поставленных целей. Инвестиционный проект, начиная от инвестиционной идеи до реализации системы управления, состоит из трех фаз: прединвестиционной; инвестиционной; эксплуатационной (оперативной). Совокупность проводимых работ по организации и созданию систем управления удобно представлять в виде сетевых моделей (графиков). Детальные сетевые графики содержат сотни и тысячи операций, вид которых определяется в значительной степени сложностью создаваемой системы управления и спецификой организации, для которой она проектируется. Рассмотрим обобщенный сетевой график укрупненных этапов разработки и создания системы управления во взаимосвязи с фазами инвестиционного проекта, дающий общее представление об основных этапах разработки и позволяющий проследить развитие системы от идеи до эксплуатации. Он представляет собой графическое изображение комплекса работ по проекту и характера их взаимосвязей.
Основными элементами сетевого графика являются: работа, событие, путь. Работа на сетевом графике изображается чаще всего вектором (дугой) и характеризует трудовой процесс, который требует времени и необходимых ресурсов (действительная работа), или фиктивная работа, то есть процесс, не требующий затрат ресурсов, но имеет определенную продолжительность. На сетевом графике фиктивная работа изображаются пунктиром вектора (дуги), отражающие логическую взаимосвязь между работами, то есть указывающие на то, что возможность начала одной работы зависит от результатов первой. События на сетевом графике изображаются обычно «кружком» и означают определенное состояние при выполнении работ. Различают начальное событие, то есть событие, за которым следует работа и конечное событие, то есть событие, которому предшествует данная работа.
Начальное событие отражает исходное состояние выполнения комплекса предстоящих работ, а завершающее событие отражает результаты выполнения всех работ. Расчет путей на сетевом графике осуществляется при определении последовательности работ, когда конечное событие каждой работы совпадает с начальным событием другой работы. Максимальный путь по итогам проводимых расчетов называется «критическим». Это означает то, что если необходимо проводить какие-либо работы, выходящие за пределы критического пути, тогда следует найти дополнительные ресурсы. Сетевое планирование осуществляется путем последовательного проведения расчетов этапов построения сетевой модели и оценки ее параметров. Расчеты проводятся в следующей последовательности: на первом этапе формулируется перечень работ, который необходим для решения поставленной задачи; на втором этапе устанавливается взаимосвязь между работами и технологическая последовательность их проведения; на третьем этапе идет процесс построения сетевого графика; на четвертом этапе осуществляется оценка продолжительности выполнения работ. Обоснованность проводимых расчетов при построении сетевых графиков определяется точностью исходных данных. Достоверные оценки продолжительности работ могут быть получены на основе предварительно созданных нормативов трудоемкости по отдельным работам. При отсутствии нормативной базы расчет продолжительности выполнения работ осуществляется на основе вероятностных экспертных оценок, которые даются исполнителями работ. Эксперты, как правило, дают три оценки: минимальную оценку продолжительности (tmin); максимальную оценку продолжительности (tmax); наиболее вероятностную оценку продолжительности (гнв).
Анализ методов и подходов оценки эффективности информационных технологий и постановка задач исследования
Использование интегрированной единой системы управления ресурсами компании может дать огромные преимущества предприятию в организации эффективного управления компанией, увеличения быстроты реакции на изменения внешней среды, повышении качества обслуживания клиентов. Владение подобной системой является довольно существенной статьей затрат компании, и польза от этих затрат должна быть тщательно рассчитана и проанализирована. Проблема оценки эффективности внедрения ИТ возникла с появлением автоматизированных систем управления (АСУ). Первые методические разработки появились в 1965-1969 годах. В то время были опубликованы: «Методика определения экономической эффективности применения ЭВМ в управлении производством» (Минск, ЦНИИТУ, 1967 г.); «Методы и практика определения эффективности капитальных вложений и новой техники» (вып. 16. М., «Наука», 1969 г.). Позднее появляются материалы по оценке экономической эффективности АСУ: «Методика определения экономической эффективности АСУ производством» (М., ЦНИИКА, 1970 г.); «Методика определения экономической эффективности автоматизированных систем управления производством» (М., НИИТЭХИМ, 1971 г.); «Временная методика определения экономической эффективности автоматизированных систем управления предприятием» (М., 1972 г.); «Методика определения фактической экономической эффективности АСУП» (Пермь, 1973 г.). В 1975 г. утверждается постановлением Государственного комитета Совета Министров СССР и президиума Академии наук СССР "Методика определения экономической эффективности автоматизированных систем управления предприятиями и производственными объединениями", разработанная на основе "Временной методики определения экономической эффективности автоматизированных систем управления предприятиями" (1972 г.). В 1977 г. постановлением ГКНТ СССР, Госплана СССР, Президиума АН СССР, Госкомитета по делам изобретений и открытий СМ СССР утверждена "Методика определения экономической эффективности использования в народном хозяйстве новой техники, изобретений и рационализаторских предложений". В начальный период появления АСУП (автоматизированная система управления предприятием) обоснование экономической целесообразности ее создания происходило по схеме, которая предназначалась для расчета экономической эффективности от внедрения новой техники в производство. Схема строилась на традиционном определении экономической эффективности капитальных вложений. Рассчитывался годовой экономический эффект путем сравнения исходных показателей по себестоимости и затрат на увеличение производственных основных и оборотных фондов с показателями, полученными после внедрения мероприятия по новой технике, и умножения полученных результатов на годовой объем производства. Однако, практика внедрения АСУП показала, что для оценки экономической эффективности требуется своя методология и специфические подходы.
Оказалось недостаточным рассматривать создание АСУ только как внедрение новой техники в производство. Были установлены факторы, действие которых определяло эффективность автоматизации управления. Считалось, что экономическая эффективность АСУ на базе ЭВМ обеспечивается за счет следующих факторов: высокой скорости выполнения операций по сбору, передаче, обработке и выводу информации за счет высокой производительности средств; применения современных методов планирования, обеспечивающих рациональное использование производственных ресурсов; непрерывного оперативного контроля над ходом выполнения плана на основе своевременной и достоверной информации о состоянии производства; повышения качества учета, планирования, контроля и регулирования. Среди многообразия способов оценки эффективности информационных проектов можно выделить два основных подхода: традиционный подход. Данный подход основан на оценке непосредственной (прямой) финансовой отдачи от проекта и опирается на предположении, что практически все преимущества от внедрения информационной системы можно напрямую подсчитать; комбинированный подход.
Его суть состоит в том, что производится оценка как финансовых эффектов от внедрения информационной системы (снижение стоимости и продолжительности операционных процессов), так и нефинансовой составляющей (повышение: лояльности клиента, ускорение темпов вывода на рынок новых продуктов, повышение качества управленческих решений.
Дисконтирование потоков денежных средств на предприятии
Денежные потоки представляют собой совокупность денежных средств, поступающих на счета организация или в кассу по мере реализации проектов (входящий денежный поток) и выплачиваемые денежные ресурсы (выходной денежный поток).
Выходной денежный поток представляет собой величину финансовых результатов от реализации проектов. Источниками образования входного денежного потока являются выручка от реализации продукции (услуг), кредиты и заемные средства внешних банковских структур, акционерный капитал, привлекаемый за счет дополнительной эмиссии акций, прочие внереализационные доходы.
Выходной денежный поток состоит из инвестиционных затрат, текущих финансовых платежей по проекту, которые включают производственно-сбытовые издержки без учета амортизационных отчислений на основные активы, платежи за кредиты и заемные средства, налоги, прочие платежи из прибыли.
Чистый денежный поток (Cash Flow) рассчитывается как разность между реальным притоком и реальным оттоком денежных средств за определенный интервал времени при инвестиционном процессе: где: NCFt - чистый денежный поток в t-м интервале времени; CIFt - входной денежный поток в t-м интервале времени; COFt - выходной денежный поток в t-м интервале времени. В качестве интервала инвестиционного периода могут быть приняты месяц, квартал, год.
Инвестиционные проекты, как правило, имеют различную интенсивность денежных потоков в течение отдельных интервалов времени. На первоначальном этапе чистый денежный поток может быть отрицательным. Положительное значение он принимает на стадии эксплуатации проекта, когда текущие поступления превышают размеры текущих платежей.
При оценке эффективности инвестиционных проектов следует учитывать постоянно меняющуюся ценность денежных потоков, которые организация затрачивает или получает в различные моменты времени. Соизмерение во времени денежных потоков осуществляется с помощью их дисконтирования, то есть процедуры приведения денежных потоков к единому моменту времени. Точкой приведения в экономических расчетах, как правило, принимается момент, который соответствует началу инвестиционного процесса, то есть к началу инвестирования проекта. Схема приведения текущего аналога денежных потоков к первоначальному моменту времени инвестирования приведен на рис. 2.2.
Процедура дисконтирования состоит в умножении денежных потоков, имеющих место на t-м интервале времени инвестиционного проекта на коэффициент дисконтирования. Коэффициент дисконтирования определяется (ott) следующим образом:
Экономический подход, основанный на процедуре дисконтирования базируется на предположении, что потенциальный инвестор, который имеет в определенный момент времени сумму денежных средств (PV) может их вложить в некоторый источник накопления средств. Например, депозитный счет в банке, который гарантирует вкладчику определенный доход в процентах за год. Тогда вкладчик через Т лет должен получить следующий доход:
Сумма PV для собственника капитала является эквивалентом суммы FV через t лет, а величина PV будет определяться следующим образом:
То есть сумма PV является текущим эквивалентом суммы FV, которая будет получена через t лет. Выбор ставки дисконта обусловлен конкретным инвестиционным проектом. Для установления величины ставки дисконта можно воспользоваться депозитным процентом по вкладам в надежный банк или процентом доходов по государственным облигациям, которые корректируются с учетом рисков. Ставка дисконтирования может быть изменена по желанию инвестора, но таким образом, чтобы обеспечить потери от возможных рисков.
Метод чистого дисконтированного дохода. В основе данного метода заложено следование основной целевой установке, определяемой собственниками компании - повышение ценности фирмы, количественной оценкой которой служит ее рыночная стоимость. Этот метод основан на сопоставлении величины исходных инвестиций (1С) с общей суммой дисконтированных чистых денежных поступлений, генерируемых ею в течение прогнозируемого срока. Поскольку приток денежных средств распределен во времени, он дисконтируется с помощью ставки г, устанавливаемой аналитиком (инвестором) самостоятельно исходя из ежегодного процента возврата, который он хочет или может иметь на инвестируемый им капитал.
Влияние факторов риска и неопределенности на эффективность инновационных проектов
Частные предприниматели, руководители акционерных обществ и фирм не могут позволить значительных ошибок при разработке инновационно -инвестиционных проектов. Поэтому, до начала реализации инвестиционного проекта с особой тщательностью проверяется обоснованность всех расчетов, положенных в основу определения инвестиционных издержек, текущих доходов и расходов. Наряду с этим учитываются возможные изменения в уровне цен, технике и технологии, продолжительности периода эксплуатации производственного объекта и другие факторы.
ИАИСУ разрабатывается, базируясь на вполне определенных предположениях относительно капитальных и текущих затрат, объемов реализации произведенной продукции, цен на товары, временных рамок проекта. Вне зависимости от качества и обоснованности этих предположений будущее развитие событий, связанных с реализацией проекта, всегда неоднозначно. Это основная аксиома любой предпринимательской деятельности. В этой связи практика инновационно-инвестиционного проектирования рассматривает в числе прочих, аспекты неопределенности и риска.
Инвестиционное решение называется рискованным или неопределенным, если оно имеет несколько возможных исходов. При оценке эффективности инновационно - инвестиционных проектов, связанных с ИАИСУ, рассматриваются такие ситуации, когда все возможные последствия любого рискованного решения известны, либо их можно предвидеть и, как следствие, рассчитать возможный результат от любого изменения ситуации. Для экономического анализа риска инвестиционных расходов в условиях неопределенности в экономической литературе рекомендуется использовать анализ безубыточности и динамичности, методы определения требуемой нормы прибыли, метод определения вероятностей исходов и ряд других методов.
Рассчитывая эффективность инновационно - инвестиционных проектов, необходимо учитывать, что их реализация происходит в условиях неопределенности, то есть неполной, неточной и изменяющейся информации по предприятию, реализующему инновационно - инвестиционный проект, финансовому состоянию инвесторов и кредиторов, экономической ситуации на внутреннем и внешнем рынках. В широком смысле наличие риска свидетельствует о возможности изменения показателей эффективности инвестиционного проекта в различных направлениях от некоторых средних значений.
Поскольку для всех участников инвестиционного проекта прежде всего важно выявить и снизить возможность негативных отклонений показателей его эффективности, то, как правило, риск рассматривается в более узком смысле, т. е. как возможность ухудшения проектных экономических показателей. В Методических рекомендациях по оценке эффективности инвестиционных проектов под риском понимается «возможность возникновения таких условий, которые приведут к негативным последствиям для всех или отдельных участников проекта». Если для какого-то инновационно - инвестиционного проекта разработан основной вариант его реализации, то с учетом наличия факторов риска и неопределенности показатели его эффективности называются ожидаемыми. При этом базисный вариант инновационно - инвестиционного проекта основывается на умеренно пессимистических оценках показателей эффективности проекта.
Организационно-экономическая система реализации проекта должна включать специальные механизмы, позволяющие снизить риск или уменьшить связанные с ним неблагоприятные последствия. В этих целях рекомендуется разрабатывать правила поведения работников при возникновении неблагоприятных ситуаций, а также специальные механизмы стабилизации (за счет дополнительных затрат на создание резервов и запасов, совершенствования технологии, материального стимулирования повышения качества продукции и др.).
Для учета факторов неопределенности и риска при оценке эффективности проекта используется вся имеющаяся информация об условиях его реализации, в том числе и не выражающаяся в форме каких-либо вероятностных законов распределения. При этом могут использоваться следующие три метода (в порядке повышения точности):
1. Проверка устойчивости: корректировка параметров проекта и экономиче ских нормативов, формализованное описание неопределенности. Метод провер ки устойчивости предполагает разработку сценария реализации инновационно инвестиционного проекта в наиболее вероятных или наиболее «опасных» для ка ких-либо участников условиях. Влияние факторов риска на норму дисконта при этом не учитывается. Проект считается устойчивым и эффективным, если во всех рассмотренных ситуациях интересы участников соблюдаются, а возможные неблагоприятные последствия устраняются за счет созданных запасов и резервов или возмещаются страховыми выплатами. Степень устойчивости по отношению к возможным изменениям условий реализации проекта может быть охарактери зована показателями предельного уровня объемов производства, цен производи мой продукции и других параметров проекта. Предельное значение параметра проекта для года его реализации t определяется как такое значение этого пара метра в t-ом году, при котором чистая прибыль данного года становится нуле вой. Одним из наиболее важных показателей этого типа является точка безубыточности, характеризующая объем продаж, при достижении которого выручка от реализации продукции равна сумме издержек производства.
Комов Илья Сергеевич
Недавно мой друг, программист, рассказал, что он не читает требования, а вместо этого приглашает аналитика на чашку чая, они вместе садятся, и аналитик рассказывает, что должно быть реализовано. Мой друг - умный человек и хороший программист, и причина, почему он получает знания о требованиях именно так, не в том, что ему лень читать документацию, а в том, что, даже прочитав ее, он до конца не разберется, что же надо сделать. В данной статье я хочу рассказать, как можно написать требования к программному продукту так, что программисты не просто используют требования, но и участвуют в их написании; на основе собственно опыта я хочу показать, каким образом можно описать требования, чтобы эти описания были достаточными для реализации системы.
Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.
Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.
Вся документация на наш программный продукт состояла из следующих разделов:
- Общая часть
Список терминов и определений
Описание бизнес-ролей - Требования
Бизнес-требования- Общие сценарии
- Сценарии использования
- Алгоритмы и проверки
Нефункциональные требования
Требования к интеграции
Требования к пользовательскому интерфейсу - Реализация
- Тестирование
- Руководства
- Управление
Системные требования описывали свойства и методы всех объектов системы.
Нефункциональных требований в данной статье мы касаться не будем. Могу лишь отослать вас к отличной книге Architecting Enterprise Solutions авторов Paul Dyson, Andrew Longshaw.
Требования к интеграции описывали низкоуровневый интерфейс взаимодействия новой системы с несколькими другими системами компании. Здесь мы их рассматривать не будем.
Требования к пользовательскому интерфейсу – отдельная большая тема, возможно, для другой статьи.
Также здесь я не буду касаться других разделов документации, которые относятся к реализации, тестированию, руководствам и управлению.
Давайте рассмотрим подробнее, что такое список терминов и зачем он нужен.
Список терминов и определений
Очень часто при обсуждении функциональности системы разговор заходит в тупик. Еще хуже, если стороны расходятся, думая, что обо всем договорились, но в результате имеют разное понимание того, что надо сделать. Это происходит не в последней степени из-за того, что изначально участники проекта не смогли договориться о том, что значат те или иные термины. Бывает, что даже самые простые слова вызывают проблемы: что такое пользователь, чем отличается группа от роли, кто является клиентом. Поэтому в отличие от описания бизнес-ролей для терминов необходимо давать как можно более точные определения.Поясню это на примере термина Пользователь . Википедия дает такое определение:
Пользователь - лицо или организация, которое использует действующую систему для выполнения конкретной функции.
Но нас оно не устраивало по нескольким причинам. Во-первых, в систему может зайти только человек, но не организация. Во-вторых, для нашей системы некорректно настоящее время глагола «использует» - система хранит данные о неактивных или удаленных пользователях, т.е. о тех, которые использовали систему ранее, но не могут в настоящее время. И наконец, у нас есть данные о потенциальных пользователях. Например, мы регистрируем сотрудника компании-клиента, который в дальнейшем может получить (а может и не получить) доступ в систему. Наше определение:
Пользователь
- человек, который имеет, имел, или, возможно, будет иметь доступ в систему для совершения операций.
Теперь программист, прочитав определение, сразу поймет, почему свойство Логин
в объекте Пользователь не обязательное.
Термины связаны друг с другом. В термине Пользователь используется «операция», поэтому приведу и ее определение:
Операция - совокупность действий, составляющих содержание одного акта бизнес-деятельности. Операция должна соответствовать требованиям ACID (Atomicity, Consistency, Isolation, Durability). Совокупность операций одного модуля представляет интерфейс взаимодействия клиент-сервер этого модуля.
Как видите, это определение очень важно для всей системы – оно не только связывает пользователя и его бизнес-действия с тем, что должно быть реализовано, но и накладывает требования на то, КАК должна быть реализована система (это КАК было определено ранее при разработке архитектуры) – бизнес-действия внутри операции должны быть внутри транзакции.
Работа над списком терминов происходила постоянно. Мы поддерживали его полноту, т.е. старались, чтобы в документации не было термина, который бы не был определен в этом списке. Кроме того, были случаи, когда мы меняли термины. Например, по прошествии нескольких месяцев с начала написания требований мы решили заменить Контрагент на Компания. Причина была проста: оказалось, что никто не в состоянии в речи, при разговоре, использовать слово «контрагент». А если так, то он должен был быть заменен на что-то более благозвучное.
Часто бывали случаи, когда приходилось прерывать обсуждение и лезть в требования, чтобы понять, подходит ли обсуждаемая функциональность под существующие определения. И для того, чтобы поддержать непротиворечивость требований, мы в итоге должны были или изменять реализацию, или корректировать описания терминов.
В итоге в списке у нас оказалось порядка 200 бизнес- и системных определений, которые мы использовали не только во всей документации, включая, например, и технический дизайн, разрабатываемый программистами, но и в разговоре, при устном обсуждении функциональности системы.
Второй частью, на которую опиралась вся документация, было описание бизнес-ролей.
Описание бизнес-ролей
Все знают, что используют систему пользователи. Но даже в небольшой системе они обладают разными правами и/или ролями. Наверное, самое простое деление – это администратор и рядовой пользователь. В большой системе ролей может быть несколько десятков и аналитику необходимо заранее об этом подумать и указывать роли при описании общих сценариев (смотри ниже) и в заголовках сценариев использования. Список бизнес-ролей используется для реализации групп и ролей пользователей, назначения им функциональных прав, он необходим тестировщикам, чтобы тестировать сценарии под нужными ролями.Бизнес-роли пользователей нам не пришлось выдумывать, поскольку в компании были устоявшиеся отделы, роли, функции. Описание ролей было дано на качественном уровне на основе анализа основных функций сотрудников. Окончательное наделение ролей конкретными правами происходило ближе к концу разработки, когда набор функциональных прав стал устойчивым.
Пара примеров:
Уровни требований
Одной из важных концепций, которую мы применяли при разработке требований, было разделение их на уровни. Алистер Коберн в книге Современные методы описания функциональных требований к системам выделяет 5 уровней. Мы использовали 4 – три уровня бизнес-требований плюс системные требования:Бизнес-требования
- Общие сценарии (соответствует уровню очень белого у Коберна)
- Сценарии использования (соответствует голубому)
- Алгоритмы и проверки (скорее черный)
Кроме того наши требования представляли из себя дерево (с циклами). Т.е. общие сценарии уточнялись сценариями использования, которые, в свою очередь, имели ссылки на проверки и алгоритмы. Поскольку мы использовали wiki, физическая реализация такой структуры не представляла проблем. Сценарии использования, алгоритмы и проверки использовали объекты, их свойства и методы, описанные на системном уровне.
Такая методология позволяла нам с одной стороны описывать текущий сценарий настолько подробно, насколько нужно на данном уровне, вынося детали на нижний уровень. С другой стороны, находясь на любом уровне можно было подняться выше, чтобы понять контекст его выполнения. Это так же обеспечивалось функциональностью wiki: сценарии и алгоритмы были написаны на отдельных страницах, а wiki позволяла посмотреть, какие страницы ссылаются на текущую. Если алгоритм использовался в нескольких сценариях, то он в обязательном порядке выносился на отдельную страницу. Такие фрагменты программисты обычно реализовывали в виде отдельных методов.
На картинке ниже представлена часть нашей иерархии (о содержании речь пойдет дальше).
Важно отметить, что если системный уровень описывал все без исключения объекты системы, то сценарии были написаны далеко не для всех случаев поведения пользователя. Ведь многие объекты, по сути, являлись справочниками, и требования к ним более-менее очевидны и похожи. Таким образом мы экономили время аналитика.
Интересен вопрос, кому в проектной команде какой из уровней нужен. Будущие пользователи могут читать общие сценарии. Но уже сценарии использования для них сложны, поэтому аналитик обычно обсуждает сценарии с пользователями, но не отдает их им для самостоятельного изучения. Программистам обычно нужны алгоритмы, проверки и системные требования. Вы однозначно можете уважать программиста, который читает сценарии использования. Тестировщикам (как и аналитикам) нужны все уровни требований, поскольку им приходится проверять систему на всех уровнях.
Использование wiki позволяло работать над требованиями параллельно всем членам проектной команды. Замечу, что в один и тот же момент разные части требований находились в разных состояниях: от находящихся в работе до уже реализованных.
Бизнес-требования
Общие сценарии
Корневая страница нашего дерева требований состояла из общих сценариев, каждый из которых описывал один из 24 бизнес-процессов, подлежащих реализации в данном модуле. Сценарии на странице располагались в той последовательности, в которой они осуществлялись в компании: от создания объекта с проданными товарами, до передачи их клиенту. Некоторые специфические или вспомогательные сценарии помещались в конце в отдельном разделе.Общий сценарий – это последовательность шагов пользователя и системы для достижения определенной цели. Описания общих сценариев были значительно менее формальны по сравнению со сценариями использования, поскольку они не предназначались для реализации. Основная цель общего сценария – это обобщить сценарии использования, подняться над системой и увидеть, что же в конечном итоге хочет сделать пользователь, и как система ему в этом помогает. Хочу заметить, что общие сценарии также содержали шаги, которые пользователь осуществлял вне системы, поскольку надо было отразить его работу во всей полноте, со всеми этапами, необходимыми для достижения бизнес-цели. На этом уровне хорошо видна роль системы в работе сотрудника компании, видно какая часть этой работы автоматизирована, а какая нет. Именно здесь становилось ясно, что некоторая последовательность действий, которую мы предлагали выполнить пользователю в системе, избыточна, что часть шагов можно сократить.
Некоторые другие цели общих сценариев:
- упорядочение знаний о работе пользователей и системы
- согласование бизнес-процессов с будущими пользователями
- основа для понимания того, что требования полны, что ничего не упущено
- входная точка при поиске нужного сценария или алгоритма
Как видите, только половина шагов автоматизирована, да и те описаны как можно более кратко. Также из первого шага видно, что ручной перевод задания на печать в статус ‘В работе’ в принципе лишний, можно упростить работу пользователя и автоматически переводить задание в этот статус при печати.
Ссылка «Задание на печать», указывающая на описание объекта в системных требованиях, лишняя, поскольку никому не требуется перепрыгнуть на него из общего сценария. А вот ссылка «пакетная печать документов на груз» важна – она ведет на сценарий использования, формально описывающий действия пользователя и системы.
Наши сценарии использования имели следующий формат:
- Заголовок со следующими полями:
статус (В работе | Готов к рецензированию | Согласован)
пользователи (по описанию бизнес-ролей)
цель
предусловия
гарантированный исход
успешный исход
ссылка на описание пользовательского интерфейса (разработанного проектировщиком интерфейсов)
ссылка на сценарий тестирования (заполнялось тестировщиками) - Основной сценарий
- Расширения сценария
Сценарии использования
Сценарий использования содержал пронумерованные шаги, которые в 99% случаев очевидным образом начинались со слов Пользователь или Система . Нумерация важна, поскольку позволяла в вопросах и комментариях сослаться на нужный пункт. Каждый шаг – это обычно простое предложение в настоящем времени. Проверки и алгоритмы выносились на следующий уровень и часто на отдельные страницы, чтобы упростить восприятие сценария, а также для повторного использования.Приведу сценарий использования, на который ссылается общий сценарий выше.
Часто аналитики рисуют пользовательский интерфейс и на его основе пишут сценарии, объясняя это тем, что так нагляднее. Доля истины в этом есть, но мы придерживались позиции, что интерфейс – это дело проектировщика интерфейса. Сначала аналитик описывает, что должно происходить, а затем проектировщик интерфейса рисует эскиз web-страницы или диалога. При этом бывало так, что сценарий приходилось менять. В этом нет ничего страшного, ведь наша цель - спроектировать все части системы так, чтобы было удобно пользователю. При этом каждый участник проектной команды, будь то аналитик или проектировщик интерфейса, обладая специфическими знаниями и внося свой вклад в общее дело, оказывает влияние на работу других членов команды проекта. Только вместе, объединив усилия, можно получить отличный результат.
Алгоритмы и проверки
Интересная проблема возникла при написании алгоритмов. Аналитик пытался их описать как можно более полно, т.е. включать все возможные проверки и ответвления. Однако получившиеся тексты оказывались плохо читабельны, и, как правило, все равно какие-то детали упускались (вероятно, сказывалось отсутствие компилятора -). Поэтому аналитику стоит описывать алгоритм настолько полно, насколько это важно в плане бизнес-логики, второстепенные проверки программист сам обязан предусмотреть в коде.Например, рассмотрим простой алгоритм ниже.
В алгоритме указана всего одна проверка, но очевидно, что при написании кода метода программист должен реализовать проверки на входные параметры; выбросить исключение, если текущий пользователь не определен и т.д. Также программист может объединить данный алгоритм с алгоритмами переходов в другие статусы и написать единый непубличный метод. На уровне API останутся те же операции, но вызывать они будут единый метод с параметрами. Выбрать лучшую реализацию алгоритмов – это как раз компетенция программиста.
Системные требования
Как известно, программирование – это разработка и реализация структур данных и алгоритмов. Таким образом, по большому счету, все, что надо знать программисту – это структуры данных, необходимые для реализации системы, и алгоритмы, которые ими манипулируют.При разработке системы мы использовали объектно-ориентированный подход, а поскольку в основе ООП лежат понятия класса и объекта, то наши структуры данных – это описания классов. Термин «класс» специфичен для программирования, поэтому мы использовали «объект». Т.о. объект в требованиях равен классу в объектно-ориентированном языке программирования (в скобках замечу, что в паре разделов требований пришлось изгаляться, чтобы в тексте разделить объект-класс и объект-экземпляр этого класса).
Описание каждого объекта располагалось на одной wiki-странице и состояло из следующих частей:
- Определение объекта (копия из списка терминов)
- Описание свойств объекта
- Описание операций и прав
- Данные
- Дополнительная информация
Первая таблица каждого объекта описывала признаки его свойств, необходимые для того, чтобы программист смог создать структуры данных в БД и реализовать объект на сервере приложения:
Название
Названием свойства оперирует как пользователь (например, «я изменил номер счета», Номер – свойство объекта Счет), так и проектная команда. Повсеместно в документации использовались ссылки на свойства в виде простой нотации Объект.Свойство, очевидной для любого участника проекта.
Тип
Мы использовали Datetime, Date, Time, GUID, String, Enum, Int, Money, BLOB, Array(), Float, Timezone, TimeSpan. Тип имел отражение на всех уровнях приложения: на уровне БД, сервера приложения, в пользовательском интерфейсе в виде кода и графического представления. Каждому типу было дано определение, чтобы их реализация не вызывала вопросов у программистов. Например, было дано такое определение типу Money: содержит вещественное число с точностью до 4-го знака после запятой, число может быть отрицательным и положительным; одновременно со значением система хранит валюту; валюта по умолчанию - российский рубль.
Признак редактируемости
Да
или Нет
в зависимости от того, позволяет ли система пользователям менять значение этого свойства в операции редактирования. В нашей системе это ограничение реализовывалось на сервере приложения и в пользовательском интерфейсе.
Признак наличия нуля
Да
или Нет
в зависимости от того, может ли поле не содержать значения. Например, поле типа Bool
должно содержать одно из возможных значений, а поле типа String обычно может быть пустым (NULL
). Это ограничение реализовывалось на уровне БД и на сервере приложения.
Признак уникальности
Да
или Нет
в зависимости от того, является ли это поле уникальным. Часто уникальность определяется на группе полей, в этом случае у всех полей в группе стояло Да+
. Это ограничение реализовывалось на уровне БД (индекс) и на сервере приложения.