Поиск в Интернете

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

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

Рассмотрим этапы бизнес-реинжиниринга на примере системы управления затратами. В литературе систему управления затратами называют оперативным контроллингом.

Этапы бизнес-реинжиниринга

В процессе бизнес-реинжиниринга проводится реструктуризация предприятия. Традиционно выделяют следующие этапы реинжиниринга.

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

2. Обратный инжиниринг - разработка модели организации «Как есть».

3. Прямой инжиниринг - разработка модели «Как должно быть».

4. Реинжиниринг - разработка комплекса мероприятий для перехода от существующей организации («Как есть») к желаемой («Как должно быть»). Для вновь создаваемого предприятия этап моделирования существующей организации отсутствует, сразу же проектируется желаемая модель.

5. Внедрение - выполнение комплекса мероприятий реинжиниринга (реорганизации, разработки информационной системы, программирования и др.).

Инструменты для моделирования существующей и желаемой структур одинаковы, поэтому рассмотрим этапы проектирования на примере прямого инжиниринга (рис. 2).

Определение бизнес-структуры

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

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

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

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

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

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

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

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

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

Моделирование организационной структуры

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

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

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

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

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

Моделирование информационной структуры

Диаграмма потоков данных имеет еще одно преимущество: совмещение функций и объектов, отображает информационную структуру. Дальнейшим развитием служит реализация модели с использованием объектно-ориентированных языков программирования (например, Visual Basic или C++) или на основе СУБД. Объекты (хранилища данных, информационные потоки и внешние сущности) диаграммы, реализованной средствами BPWin (Platinum), могут быть экспортированы в ERWin (Platinum). Для этого в BPWin предусмотрена возможность описания объекта диаграммы потоков данных в виде сущности или атрибута с указанием способа воздействия функций на объекты (создание, обновление, чтение, удаление). В реляционной модели правила взаимодействия функций и объектов реализуются в виде триггеров (хранимых процедур). Триггеры поддерживают целостность данных при обновлении, удалении и создании (добавлении) данных путем каскадных изменений в связанных таблицах. Изменение данных требует определенных полномочий, таким образом, способ воздействия функций на объекты вызывает необходимость администрирования данных.

После того, как сущности и атрибуты будут экспортированы в ERWin, необходимо задать ключевые атрибуты сущностей и установить отношения между объектами. Полученная концептуальная модель (рис. 5) может быть экспортирована в СУБД или импортирована средствами Visual Basic в виде формы для работы с данными.

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

Для разрешения подобного рода проблем следует обратиться к денормализации и рассмотреть вопросы проектирования хранилищ данных. Хранилища данных проектируются на основе существующей концептуальной модели и, по сути, дублируют данные. Однако при этом затраты на хранение избыточной информации окупаются повышением эффективности выполнения запросов. Использование современных инструментальных средств OLAP (On Line Analytical Process) обработки многомерных данных позволяют извлечь данные с различной степенью детализации и использовать полученную информацию для принятия управленческих решений. Обычно хранилище данных размещается на специально выделенном компьютере. Сброс данных в хранилище производится согласно установленному регламенту.

Проектирование хранилища данных опирается на методологию многомерного моделирования DM (Dimensional Modeling), которая поддерживается инструментальным средством ERWin (Platinum). Для расчета доли постоянных и переменных затрат нужна информация о различных видах затрат и количестве изделий за период, не менее года. Выбор базы отнесения затрат для подразделений требует информации о центрах затрат, производимой ими продукции и взаимно оказанных услугах, ресурсах и ограничениях. Пример структуры хранилища данных приведен на рис. 6.

Хранилище данных может быть реализовано на основе Oracle Express, причем система оперативного анализа, построенная на основе реляционной модели, так же популярна, как и на основе иерархической модели. Представителем реляционного направления OLAP является Oracle Discoverer. Выбор платформы Oracle отнюдь не означает отказа от существующих наработок в среде разнородных СУБД. Серверная часть, реализованная на основе Oracle, не исключает возможности существования клиентских приложений на базе Access, Visual FoxPro и прочих.

Взаимное влияние организационной и информационной структур

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

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

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

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

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