Текст книги "Хватит платить за все! Снижение издержек в компании"

Пример мероприятий по снижению издержек в телекоммуникационной компании

В результате анализа деятельности основными функциональными областями для снижения издержек признаны:

• продажи и обслуживание;

• управление сетью и телекоммуникационной структурой;

• управление продуктами;

• закупки;

• управление персоналом;

• управление информационными технологиями (ИТ), включая внедрение ERP-системы[13]13
  ERP-система (Enterprise Resource Planning System) – система планирования ресурсов предприятия – это интегрированная система на базе информационных технологий для управления внутренними и внешними ресурсами предприятия


[Закрыть];

• администрация;

• управление имущественным комплексом;

• капитальное строительство;

• управление транспортным хозяйством.

Таблица 7.4. Инициативы по снижению издержек в телекоммуникационной компании

¹ IMS (IP Multimedia Subsystem) – спецификация передачи мультимедийного содержимого в электросвязи на основе протокола IP.

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

¹ Под понятием разделяемые сервисы (Shared Services) понимают консолидацию и централизацию однородных функций бизнеса в пределах одного предприятия высококвалифицированному внутреннему отделу или группе, либо аналогично – между группой компаний.

Организация проекта

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

Таблица 7.5. Роли сотрудников в проекте

Резюме

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

1) постановка (уточнение) целей и задач проекта;

2) диагностика издержек и определение перспективных направлений их снижения;

3) диагностика деятельности (бизнес-процессы, потери, организационная структура, персонал);

4) анализ деятельности по перспективным направлениям снижения издержек;

5) формирование программы мероприятий по снижению издержек;

6) внедрение (реализация) программы мероприятий по снижению издержек;

7) оценка результатов внедрения и/или корректировка программы.

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

• краткое наименование мероприятия;

• краткое описание (суть) мероприятия;

• вид мероприятия (беззатратный, малозатратный, высокозатратный);

• срок реализации;

• экономический эффект (экономия ресурсов в течение периода, обычно в течение года);

• затраты на реализацию.

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

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

• объективная ситуация на рынке (кризис, конкурентная борьба и т. п.), прямо вызывающая необходимость сокращения издержек;

• желание собственника и/или руководства сократить издержки;

• влияние технологического прогресса (появление новых малозатратных технологий).

С другой стороны, есть силы, которые оказывают сопротивление данному проекту, а именно:

• личные интересы сотрудников, направленные на сохранение прежних доходов и влияния;

• недоверие (неполное доверие) со стороны сотрудников;

• различия в оценке текущей ситуации у инициаторов проекта и у рядовых сотрудников.

Приложения

Приложение I. Распределение бюджетов по уровням ответственности (к главе 1)

Приложение II. Пример карты процессов (к главе 3)

Приложение III. Обзор нотаций моделирования бизнес-процессов (к главе 3)

В настоящее время широко используются и очень популярны несколько стандартов описания бизнес-процессов:

• семейство стандартов IDEF (в частности, IDEFo, DFD, IDEF3);

• семейство стандартов ARIS (в частности, нотация eEPC);

• семейство стандартов UML (Usecase diagram, activity diagram);

• кроссфункциональная нотация.

Каждое из этих семейств стандартов представляет собой определенную методологию и реализовано рядом программных продуктов (CASE-средств). Наиболее популярное программное обеспечение (ПО), реализующее ту или иную методологию, представлено в табл. III.1.

Таблица III.1

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

Стандарт моделирования бизнес-процессов IDEFo был принят в качестве такового в 1981 г. Исторически он возник из стандарта SADT (Structured Analysis and Design Teqnique), активно применявшегося с конца 1960-х гг., в частности Министерством обороны США. IDEF является аббревиатурой от ICAM DEFinition. ICAM – Integrated Computer Aided Manufacturing.

Семейство стандартов IDEF включает в себя ряд графических нотаций, которые могут быть использованы для моделирования БП:

• IDEFo – стандарт описания бизнес-процессов;

• DFD – диаграмма потока данных (DataFlow Diagram);

• IDEF3 – стандарт моделирования потока работ (workflow).

Более подробное описание данных нотаций моделирования приведено далее.

ARIS расшифровывается как Arhitecture of Integrated Information Systems – архитектура интегрированных информационных систем. В методологию ARIS входит пять типов представлений моделей:

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

• функциональные модели, описывающие функции (процессы, операции), выполняемые в организации;

• информационные модели (модели данных), отражающие структуру информации, необходимой для реализации всей совокупности функций системы;

• модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели;

• модели входов и выходов, описывающие потоки материальных и нематериальных входов и выходов процедур, включая, в частности, потоки денежных средств.

В каждом из этих типов моделей есть ряд нотаций, отличающихся методами моделирования, и число этих нотаций довольно велико. В частности, ARIS Toolset поддерживает ряд нотаций языка моделирования UML – Unified Modeling Language.

Число поддерживаемых ARIS нотаций довольно велико, и описывать каждую из них нецелесообразно. Имеет смысл дать основы нотации eEPC как наиболее, на наш взгляд, применимой для моделирования бизнес-процессов.

Нотация ARIS eEPC расшифровывается следующим образом: Extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В табл. III.2 приводятся основные используемые в рамках нотации графические объекты.

Таблица III.2

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

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

Рис. III.1

На рис. III.1 видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1, «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:

• каждая функция должна быть инициирована событием и должна завершаться событием;

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

Кроме этих правил существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демоверсией продукта.

На рис. III.2 показано применение различных объектов ARIS при создании модели бизнес-процесса.

Каждый объект в системе ARIS Toolset, которая поддерживает метод описания бизнес-процессов ARIS, имеет определенный набор атрибутов. Пользователю предлагается воспользоваться стандартными атрибутами для описания объектов или ограниченным количеством так называемых пользовательских атрибутов.

Из рис. III.2 видно, что бизнес-процесс в нотации eEPC представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длительность выполнения процедур в eEPC визуально отражена быть не может. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.

Рис. III.2

Таким образом, при помощи нотации eEPC ARIS можно описывать бизнес-процесс в виде потока последовательно выполняемых работ (процедур, функций).

Аббревиатура UML расшифровывается как Unified Modeling Language– унифицированный язык моделирования.

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

Язык UML был создан в компании Rational одним из ведущих идеологов объектно-ориентированного подхода к программированию Гради Бучем (Grady Booch), совместно с Джимом Рамбо (Jim Rumbaugh) и Иваром Джекобсоном (lvar Jacobson)в 1994 г.

UML включает в себя ряд типов диаграмм, некоторые из которых могут быть использованы для моделирования бизнес-процессов. В частности, это диаграмма прецедентов (Use-case diagram) и диаграмма действий (Activity Diagram).

Диаграмма прецедентов служит для моделирования типичных сценариев работы с системой.

Диаграмма прецедентов состоит из прецедентов (use-case) – типичных взаимодействий между пользователем и компьютерной системой, и субъектов (actor) – ролей, которые пользователи играют относительно системы. Также на ней могут быть указаны отношения между прецедентами: связь расширения (extends) и связь использования (uses).

Рис. III.3. Эффективность использования различных нотаций моделирования БП

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

В основе методологии IDEFo лежат три основных понятия:

• функциональный блок (Activity Box);

• интерфейсная дуга (Arrow);

• декомпозиция (Decomposition).

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

Каждая из четырех сторон функционального блока (рис. III.4) имеет свое определенное значение (роль), при этом:

• верхняя сторона имеет значение «Управление» (Control);

• левая сторона имеет значение «Вход» (Input);

• правая сторона имеет значение «Выход» (Output);

• нижняя сторона имеет значение «Механизм» (Mechanism).

Рис. III.4

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта наименование должно быть оборотом существительного.

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

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

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

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

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

Рис. III.5

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

Рис. III.6

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEFo от других методологий классов DFD (Data Flow Diagram)и WFD (Work Flow Diagram).

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

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

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

Третьим основным понятием стандарта IDEFo является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEFo всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой и обозначается идентификатором «А-0».

Обычно IDEFo-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:

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

• ограничение количества подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя.

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

Очень важно при построении модели четко обозначить цель (purpose) и точку зрения (viewpoint)модели.

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

Необходимо понимать, что модель БП с точки зрения главного инженера и с точки зрения главного бухгалтера будут существенно различаться. Точка зрения – это своего рода «фильтр» для процесса.

В основе нотации DFD лежат следующие понятия:

• работа;

• дуга;

• внешняя ссылка;

• хранилище данных.

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

Дуги (стрелки) идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота.

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

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

Рис. III.7

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