Компьютер в бухгалтерском учете и аудите 2001'4

Home

Поиск

Издания

Контакты

k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Компания "Ключ"

Процесс решения прикладной задачи

Введение

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

Определяются основные этапы решения, строится информационная и функциональная модель системы.

В статье также показана архитектура инструментальной платформы «Экспресс», реализующая концепцию «Приложение, управляемое Моделью» и являющаяся собственной разработкой Компании Ключ – http://www.key.scn.ru.

Формулировка задачи

Задача «Управление затратами на телефонные переговоры» является актуальной для многих предприятий всех форм собственности.

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

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

Рис. 1. Выдержка из расшифровочной ведомости

Тогда как анализ затрат на телефонные переговоры может предоставить руководителю объективную и исчерпывающую информацию о структуре и распределении затрат, в том числе:

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

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

Итак, при решении задачи «Управление затратами на телефонные переговоры» необходимо:

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

Анализ и проектирование

Анализ предметной области

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

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

Телефонный звонок

Базовой единицей исходных данных является один звонок.

Каждый телефонный звонок характеризуется следующими параметрами:

Источник – номер телефона, принадлежащего предприятию;
Адресат – номер телефона абонента;
Момент звонка – дата и время звонка;
Длительность разговора;
Стоимость звонка.

Длительность и стоимость звонка позволяют произвести количественный анализ, а дата и время – временной анализ затрат на телефонные переговоры.

Оставшиеся параметры: откуда (Источник) и куда (Адресат) звонили, обеспечивают возможность проведения качественного анализа затрат. На этих параметрах мы более подробно и остановимся.

Источник

Источник – это номер телефона самого предприятия, с которого был совершен звонок.

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

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

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

Адресат

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

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

Кроме этого, для каждого абонента может быть определен его статус: личный или служебный.

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

Если статус абонента служебный, то это означает, что этот абонент принадлежит одной из организаций-контрагентов.

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

Создание информационной модели

Проанализировав предметную область и выделив в ней основные информационные элементы, мы получаем следующую информационную модель (рис. 2).

Создание функциональной модели

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

Полученная функциональная схема представлена на рис. 3.

Остановимся подробнее на каждом из блоков.

Рис. 2. Информационная модель

Рис. 3. Функциональная модель

Заведение справочной информации

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

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

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

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

Импорт данных

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

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

Классификация абонентов

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

Такая классификация позволяет получить точный и подробный анализ структуры затрат на телефонные переговоры.

Анализ затрат на телефонные переговоры

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

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

Наиболее отвечающими этим требованиям решением является использование технологии многомерного анализа данных OLAP.

Рис. 4. Направление развития

Варианты реализации

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

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

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

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

Реализация на базе инструментальной платформы «Экспресс»

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

Концепция «Приложение, управляемое Моделью»

В архитектуру платформы «Экспресс» заложена концепция «Приложение, управляемое Моделью» (MDA – Model Driven Application).

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

Design-time – настройка бизнес логики, создание и развитие модели

Rut-time – исполнение модели, интерпретация

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

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

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

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

Метамодель, то есть набор прикладных объектов (монитор входных документов, генератор выходных документов, модуль справочников, …);
Набор базовых служб (доступ к данным, сервис репозитория, сервис представления, …);
Инструментарий по созданию прикладных моделей (режим настройки системы – design-time);
Режим исполнения модели – рабочий режим системы (run-time).

Добавление уровня Метамодели приводит к появлению концепции «Класс-Тип-Экземпляр», которая расширяет привычную для программистов схему «Класс-Экземпляр». Аналогии такого развития можно найти в структурной организации распределенных информационных систем (рис. 4).

Рис. 5. Монитор входных документов (run-time)

Рис. 6. Справочники (run-time)

Рис. 7. Анализатор данных

Архитектура платформы «Экспресс»

Основными компонентами метамодели платформы «Экспресс» являются:

Монитор входных документов (рис. 5). Данный компонент предназначен для организации документооборота и занесения первичной информации в систему.
Модуль нормативно-справочной информации (Справочники, рис. 6). Компонент предназначен для работы со справочной информацией. На основании расширенной реляционной модели компонент предоставляет сервис по работе с взаимосвязанными справочниками.
Генератор выходных документов. Предназначен для формирования отчетов на основании оперативных данных и нормативно-справочной информации. Наряду с другими компонентами системы, такими как Анализатор Данных, служит для поддержки принятия решений на основе оперативных данных.
Анализатор данных (рис. 7). Анализатор данных предназначен для эффективного представления и многомерного анализа (OLAP) больших объемов информации, хранимой в базе данных системы. Анализатор данных выступает как основное средство при работе с оперативными данными и является оптимальным инструментом для менеджеров, принимающих решения.
Процессор расчетов (рис. 8). Компонент предназначен для описания и вычисления сложных расчетов, использующих большое количество данных и требующих сложного, разветвленного алгоритма. Примером задачи такого рода является, например, расчет заработной платы. В этой задаче вычисления отличаются наличием нескольких сотен видов исходных, промежуточных и итоговых результатов. Реализация таких алгоритмов процедурным способом крайне трудоемка. Представление алгоритма в виде графа позволило сделать модель открытой и легко модифицируемой. При этом не требуется программировать, достаточно простого понимания логики вычислений каждого элемента расчета и его взаимосвязей с другими элементами.
Библиотека ресурсов. Универсальный компонент по работе с моделью в режиме design-time. Библиотека реализует сервис хранения, настройки, экспорта-импорта модели. Все мониторы, реализующие какой-либо функционал в метамодели прикладной области, пользуются сервисом библиотеки ресурсов, как в режиме Design-time, когда модель изменяется, так и в режиме Run-time, когда модель интерпретируется.

Рис. 8. Модель Процессора расчетов

Подробнее об архитектуре платформы «Экспресс» и о составляющих ее компонентах можно узнать на сайте Компании Ключ http://www.key.scn.ru.

Структура приложения

По результатам анализа прикладной задачи «Учет затрат на телефонные переговоры» на базе инструментальной платформы «Экспресс» было создано прикладное решение «Экономный телефон».

Процесс создания прикладного решения состоит из следующих этапов:

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

В рамках этого прикладного решения импорт и хранение расшифровочных ведомостей был реализован при помощи Монитора входных документов. Для реализации этой части функционала настроен один тип документа — «Импорт расшифровочных ведомостей».

Рис. 9

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

Для анализа данных использовался компонент Анализатор данных. При этом в прикладном решении готовыми к использованию настроено несколько типов анализа:

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

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

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

Получить демонстрационную версию и более подробную информацию о разработанной системе «Экономный телефон» можно на сайте Компании Ключ http://www.key.scn.ru .

Трудоемкость

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

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

Собственно разработка модели представляет собой работу в режиме design-time со специализированными дизайнерами соответствующих модулей. Основную часть модели составляют декларативные элементы. Кодирование на встроенном языке применяется лишь по необходимости в случае слабо формализуемых элементов модели.

В данном конкретном случае процесс разработки прикладного решения от фазы анализа требований до завершения b-тестирования решения стоил усилий 2 человек в течение 10 дней.

Заключение

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

Если у Вас возникли вопросы или замечания, то мы с удовольствием примем их по адресу ecophone@keycompany.ru.

Третьяков М. Ю.,
Коровичев В. В.