Контроллинг и совершенствование процессов ИТ-подразделения | КомпьютерПресс

Контроллинг и совершенствование процессов ИТ-подразделения | КомпьютерПресс Аналитика

Стандартные модули комплекса > “бюджетирование” > основные понятия и структура бюджета

Бюджетом будем называть конечный продукт бюджетирования: документ с конкретными цифрами – данными бюджета.

Настройка каждого бюджета начинается с разработки структуры типового бюджета, то есть Типа бюджета, к которому будет относиться будущий бюджет. У Типа бюджета (типового бюджета) есть характеристики (параметры бюджета, параметры варианта бюджета, аналитики, источники, показатели и статьи), которые мы рассмотрим ниже. Следующий этап – создание “Описания бюджета”, в котором указывается “Тип бюджета” и “Тип периода времени”, который будет охватывать будущий бюджет (год, квартал, месяц…). Естественно, на основе одного и того же Типа бюджета может быть заведено любое количество Описаний бюджетов. Каждый бюджет, созданный на базе Описания бюджета BDG_R404, можно рассчитывать в нескольких Вариантах, которые отличаются значениями некоторых прогнозируемых Параметров.

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

Поясним эти понятия на примере типового бюджета оплаты труда в производстве. При наличии на предприятии двух производств с одинаковой системой оплаты труда удобней создать один Тип бюджета «Оплата труда в производстве», на базе которого потом будут формироваться 2 разных Описания бюджета: «Зарплата 1-го производства», «Зарплата 2-го производства». Эти бюджеты (Описания бюджетов) будут отличаться номером производства – это и есть Параметр бюджета. Если планируется увеличение сдельных расценок, каждый из этих бюджетов можно рассчитать для разных вариантов увеличения, например, при возрастании расценок на 15% и на 20%. Процент увеличения сдельных расценок – это Параметр варианта бюджета.

bdg_struct2

Для каждого типового бюджета можно описать одновременно механизмы формирования бюджета-плана, бюджета-факта и бюджета-лимита. Обязательным является только бюджет-план. План/Факт/Лимит – это Режимы данных бюджета. Режим Лимит нужен для отображения предельно допустимых значений и контроля за превышением фактическими показателями этих предельных значений. Используется редко, поэтому говоря о Режимах данных будем иногда ограничиваться упоминанием плана и факта.

У типового бюджета есть еще несколько характеристик:

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

Каждый бюджет можно просмотреть либо в разрезе Статей, либо в разрезе Аналитик.

Статьиперечень строк бюджета, который определяется на этапе создания Типа бюджета. Статьи являются едиными для всех режимов данных бюджета (плана, факта и лимита). Статьями бюджета общепроизводственных расходов могут быть вода, электроэнергия, топливо, расходы на ремонт оборудования и т.п. Количество Статей в каждом Описании бюджета неограниченно. Для каждой Статьи описывается способ отбора данных по каждому из Источников. Так как одна и та же Статья может упоминаться в разных Типах бюджетов, перечень Статей оформлен отдельным справочником. Справочник Статей бюджета содержит только код, наименование и стандартную группировку (CODEGROUP) с 5-ю уровнями вложенности.

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

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

Дополнительный анализ:  Новости рынка. СМПРО - Ваш партнер в промышленности строительных материалов

Аналитики – необязательная характеристика Типа бюджета, их количество не может превышать 10-ти.

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

Схематически можно представить, что Статья (или Аналитика) – это строка, а Показатель – колонка. Данные бюджета, которые находятся на пересечении строки и колонки, – то есть значение Показателя по конкретной Статье (Аналитике), – описывается отдельной формулой по каждому из Источников данных.

Создание всех характеристик типа бюджета реализовано отдельными уровнями (дочерними справочниками) к справочнику Типы бюджетов.

Подробности работы с вариантами смотрите в описании справочника Описания бюджетов.

Взаимосвязи характеристик бюджета рассмотрим на примере типа бюджета «Списание сырья в производстве».

НАШИ ВОПРОСЫ

  • «Плоская таблица». Все данные в мире хранятся в виде таблиц. Кому и когда вы звонили со своего мобильного, ваши штрафы, паспортные данные и все прочее… Но хранятся эти данные не в абы каких таблицах, а в «плоских». Что это за таблицы, спросите вы? Ответим, но перед этим нужно разобрать, какие бывают данные?
  • «Какие бывают данные». Данные можно разделить на две огромные группы… пока все))

Запоминаем. ВОПРОС 1: «Что такое «плоская таблица»? ВОПРОС 2: «Какие бывают данные»? ))

А теперь ПРИМЕР

Допустим вы производите и продаете какую-то продукцию. И хотите спланировать свою деятельность. Сколько вам произвести или закупить?

Вот ваша таблица со среднемесячными продажами. (Рисунок 1)

Рисунок 1

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

Рисунок 2

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

И вот тут-то вы призадумались! Как вам расположить поля? Можно использовать разные листочки, для каждого месяца свой лист (Рисунок 3)

Рисунок 3

Можно попробовать добавить строк в таблицу (Рисунок 4).

Рисунок 4

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

ТОТ ЖЕ ПРИМЕР, ТОЛЬКО с другой стороны

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

По одной линии расположены Контрагенты. Как будто вдоль прямой мы откладывали метки: Контрагент 1, Контрагент 2, .. а на эти метки клали, коробки спичек с бумажкой внутри. Математики или программисты бы сказали: «Одномерный массив (много потому что) данных», потому что одна прямая – это одномерный мир.

Рисунок 6

Вторая таблица (там, где был Контрагент и Товар) будет выглядеть так (Рисунок 7). Теперь наши коробки лежат не на прямой, а на плоскости. По одной линии мы откладываем Контрагент 1, Контрагент 2, а по другой линии откладываем Товар 1, Товар 2…А на пересечении лежит наш коробок с цифрой, с ответом на вопрос, сколько Товара N покупает Контрагент N.

Рисунок 7

Наша третья таблица выглядела бы так (нарисуем в ней циферки, чтобы легче было представлять). По одной прямой мы бы откладывали метки Контрагент 1, 2.., по другой Товар 1,2.., а по третьей Месяц 1,2…И на пересечении этих трех линий коробков был бы наш искомый коробок, с нужной нам цифрой. Это уже походе на трехмерный мир, и математики бы назвали бы это «трехмерный массив данных».

Рисунок 8

И вот мы подошли к ответу на ВОПРОС 2, и 3. ВОПРОС 2: «Какие бывают данные»? ВОПРОС 3: «Почему сложно построить большие таблицы» ?

А ТЕПЕРЬ ОТВЕТЫ

ОТВЕТ на ВОПРОС 2:

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

А то, что мы откладывали как метки по прямым (Контрагент 1,2.., Товар 1,2, Месяц 1,2..) — это были аналитические разрезы или характеристики данных, или еще говорят: «аналитики-разрезы-аналитические разрезы-характеристики данных- измерения»… (слово «измерение» скорее всего вам не знакомо, но программисты используют едва ли не чаще всего; почему, мы это узнаем чуть позже).

Дополнительный анализ:  Мнения — Россия в глобальной политике

Кстати, в нашем примере была одна бумажка с в коробке, но это для простоты, на самом деле и данных может быть очень много, В нашем примере, например, % накапливаемой скидки за эту продажу, или за цена (если мы каждому клиенту продаем по своей цене, так называемая — ценовая дискриминация), себестоимость, но это легко представить, как просто 2,3… подписанные бумажки с цифрами в нашей коробочке.

ОТВЕТ на ВОПРОС 3:

«Почему сложно построить большие таблицы»? ОТВЕТ: потому что мы живем в трехмерном измерении, а аналитических разрезов бывает на-а-а-а-много больше, чем 3. Да даже когда их 3, мы уже вынуждены напрягаться, разные таблицы или расшифровка строк. А как же быть, если аналитик больше, чем три? (ЭТО ВОПРОС 4, но дадим на него ответ сразу.)

ВОПРОС: «А как же быть, если аналитик больше, чем три»? ОТВЕТ: использовать «плоскую таблицу». Плоская таблица дает возможность упорядоченно расположить таблицу с любым количеством Аналитических разрезов.

КАК СТРОЯТСЯ ПЛОСКИЕ ТАБЛИЦЫ

Посмотрим, как они строятся?

На том же примере: Сначала у нас была одна линия, по которой мы откладывали Контрагент 1,2.. Потом появилось «две пересекающиеся линии», на пересечении которых наши данные. Потом «три пересекающиеся линии». А что если эти линии не пресекать? Если они будут параллельными?

А считать данные мы сможем прочтя строку (см. самую правую картинку на Рисунок 9). Контрагент 1, Товар 1, Март, можем добавить что-то еще, и в конце данные по продаже – 15. Кажется в такой таблице можно поместить бесконечное количество параллельных Аналитик и данных и бесконечное количество данных.

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

Организационный анализ

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

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

Рис. 5. Результаты организационного анализа в ARIS PPM

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

Процессная аналитика — process intelligence

Сейчас ИТ-подразделение в большинстве отраслей является самым затратным, при этом в случае падения объема продаж предприятия на 15-20% затраты на информационные технологии вполне могут срезать и на все 50%. Столь сложная ситуация требует от ИТ-руководителя понимания всех скрытых возможностей своего подразделения, а следовательно, знания узких мест существующих процессов.

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

Такой подход позволяет замкнуть управленческий цикл и построить систему контроллинга, которая обеспечит ИТ-руководителей необходимой информацией для принятия решений. Несмотря на серьезное сокращение затрат в ИТ-подразделениях, никто не снимает с них ответственности за качество процессов поддержки и предоставления услуг, которое оценивается исходя из того, как соблюдаются соглашения об уровне услуг (Service Level Agreement, SLA).

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

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

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

Большой объем требуемой информации и специфичность задачи анализа процессов для их дальнейшей оптимизации требуют применения специальных информационных систем для процессного анализа — Process Intelligence. По мнению Gartner, появление систем класса Process Intelligence является тенденцией, которая объясняется большой востребованностью инструментов бизнес-анализа, касающихся именно совершенствования деятельности.

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

Дополнительный анализ:  Слишком Дальний: иностранные инвесторы не спешат вкладывать в ДФО | Статьи | Известия

Рис. 1. Process Intelligence — портал руководителя ИТ-подразделения

Свойство «виды субконто»

Свойства объекта «План счетов», отвечающие за настройку дополнительных аналитических разрезов – это «Максимальное количество субконто» и «Виды субконто»:

Рисунок 1 – Свойства плана счетов на закладке «Субконто»

Максимальное количество субконто – это максимальное количество субконто, которое может быть добавлено к счету. Если указано, что максимальное количество субконто равно 2, то к счету можно добавить 1 или 2 дополнительных аналитических разреза. Максимально возможное количество субконто равно 50.

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

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

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

Совершенствование процессов ит-подразделения

Инструменты класса Process Intelligence позволяют проводить анализ процессов в различных аналитических разрезах, что дает возможность найти в них узкие места, оптимизация которых обеспечивает сокращение затрат и ускоряет процессы. Если говорить о практике реализации контроллинга для ИТ-подразделения, то здесь в качестве систем, которые представляют первичную информацию о бизнес-процессе, могут выступать продукты компаний HP, Remedy и другие системы, автоматизирующие деятельность ИТ-службы.

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

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

Рис. 2. Показатели и аналитические разрезы для ИТ-процессов

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

Число процессов, время реакции на инцидент, среднее время обработки инцидента, загрузка сотрудников Service Desk — все эти показатели нужно и можно контролировать с помощью инструментария Process Intelligence. Что касается аналитических разрезов, то тут основными являются следующие:

  • приоритет инцидента/изменения;
  • название сервиса;
  • срочность инцидента/изменения;
  • участник процесса;
  • категория инцидента/изменения;
  • отчетный период.

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

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

Рис. 3. Анализ процесса по различным разрезам

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

Особенность инструментария процессного анализа как раз заключается в том, что он дает возможность «увидеть» те процессы, которые выполняются в информационных системах. Например, инструмент ARIS Process Performance Manager (ARIS PPM) компании IDS Scheer может сформировать модели на основе информации о процессах, содержащейся в информационных системах, что позволяет скорректировать регламенты и определить различия между целевой моделью и фактической ситуацией (рис. 4).

Рис. 4. ARIS PPM — восстановление процесса

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

Заключение

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

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

  • управление инцидентами;
  • управление проблемами;
  • управление изменениями;
  • управление запросами на предоставление сервисов;
  • управление уровнем сервиса.

Практика выполненных проектов показывает, что применение инструментария Process Intelligence дает возможность сократить время выполнения процессов на 15-20% при одновременном уменьшении стоимости на 10-12%.

КомпьютерПресс 9’2009

Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector