science-review.ru
В настоящее время управление крупной организацией является сложным процессом, для решения которого необходимо решать различные задачи. Одной из таких задач является построение организационной структуры. Под структурой организации понимается состав, соотношение ее внутренних звеньев и форм, их взаимосвязи в процессе деятельности предприятия. Организационная структура компании может меняться в связи с требованиями бизнеса, законов и внешней среды.
В образовательных учреждениях организационная структура меняется особенно часто: это обусловлено введением новых образовательных стандартов, правил, требований министерства и развитием самой организации.
В МГТУ им Г.И. Носова (Университет) за последние десять лет произошло множество изменений: реорганизация двух вузов МаГУ и МГТУ им. Г.И. Носова путем их слияния, создание и расформирование множества учебных и административных подразделений. В данный момент в МГТУ им. Г.И. Носова отслеживать изменения в организационной структуре сложно. Это объясняется наличием сопряженных с непосредственным изменением процессов: выход приказа, загрузка его на корпоративный портал и внесение изменений на официальном сайте. Такой порядок работы имеет недостатки: во-первых, работа представляет два разных процесса – выгрузка данных на корпоративный портал и внесение изменений на внешнем сайте вуза, – за которые отвечают разные люди; во-вторых, установление подчиненности подразделений ректорату возможно только посредством взаимодействия с ученым секретарем вуза или руководителем подразделения, то есть отсутствие прозрачности данной информации.
Для решения этой проблемы руководство университета приняло решение о разработке внешнего программного модуля корпоративного портала вуза, позволяющего не только изменять структуру организации, но и закреплять проректора за подразделениями с соблюдением условий разграничения прав доступа.
Цель исследования состоит в формировании требований к информационному обеспечению модуля «Структура вуза».
Материалы и методы исследования
Теоретические методы: анализ, формализация, семантическое моделирование данных (методология IDEF1X), индукция, классификация, многокритериальный анализ; эмпирические методы: наблюдение, сравнение, измерение; инструменты моделирования бизнес-процессов (CA AllFusion Erwin Data Modeler).
Исходными данными послужили нормативные документы университета (приказы об изменениях, решения ученого совета и президиума ученого совета), а также результаты интервьюирования эксперта предметной области (секретаря ученого совета).
Результаты исследования и их обсуждение
Создание автоматизированной системы (АС) предполагает выполнение таких работ, как формирование требований к АС, разработку концепции АС, разработку технического задания, разработку технического проекта, создание рабочей документации и ввода в действие [1].
В рамках данного исследования представлены результаты работ по формулировке требований к информационному обеспечению, которое является частью технического задания. Информационное обеспечение (ИО) – совокупность информационных ресурсов и услуг, предоставляемых для решения управленческих и научно-технических задач в соответствии с этапами их выполнения [2].
Согласно ГОСТ 34 602-89 для информационного обеспечения АС приводят следующие виды требований:
– к составу, структуре и способам организации данных в системе;
– к информационному обмену между компонентами системы;
– к информационной совместимости со смежными системами;
– по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии;
– по применению систем управления базами данных;
– к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;
– к защите данных от разрушений при авариях и сбоях в электропитании системы;
– к контролю, обновлению и восстановлению данных;
– к процедуре придания юридической силы документам, продуцируемым [3].
Для понимания требований к информационному обеспечению модуля «Структура вуза» предварительно рассмотрим образ и сформулируем границы проекта его создания. Для ФГБОУ ВО «Магнитогорский государственный технический университет им Г.И. Носова» модуль будет представлять собой интернет-приложение, позволяющее знакомиться с актуальной организационной структурой, производить изменения на основании приказа и закреплять проректора за подразделениями, в отличие от действующего сейчас механизма просмотра структуры на сайте и узнавание о подчиненности у руководства. Для секретаря ученого совета будет предусмотрена возможность вносить изменения в структуру, выгружать данные, отслеживать управление ректоратом какого-либо подразделения. В системе будет присутствовать администратор, который будет заниматься резервным копированием и архивацией данных.
Для сторонних пользователей университета ИС будет представлять собой приложение, предоставляющее информацию об актуальной структуре университета.
Система должна обеспечить следующие функциональные возможности: создание, удаление, изменение подразделений; формирование запроса о том, кто курирует подразделение; хранение и загрузка документации по структуре; хранение истории изменения структуры университета.
Таким образом, модуль учета изменений организационной структуры вуза предназначен для обеспечения единого справочника структурных подразделений, который обеспечит учет истории изменении в подразделениях, а также позволит узнать, какой проректор за какое подразделение отвечает [4].
Одно из требований к информационному обеспечению (как было представлено выше) – это способ организации данных в системе, то есть моделирование логической и физической структуры приложения. Для того чтобы представить способ организации данных, сначала необходимо выделить объекты системы, а потом расставить связи между ними.
В ходе анализа документов предметной области, а также интервьюирования экспертов были выделены следующе объекты – подразделения, пользователи, приказы, доверенности, изменения, ректорат. Эти объекты необходимо дополнить данными – классификация подразделений, классификация документов, отдельно взять документы, должности ректората, подчиненности [5].
Для наглядности построим логическую модель данных IDEF1X (рис. 1).
Рис. 1. Логическая модель модуля «Структура вуза»
В представленных ниже таблицах приведены структура, типы данных и ограничения каждого из выделенных объектов.
Таблица «Классификация подразделений» предназначена для классификации структурных подразделений. Таблица включает в себя поля: код классификации и наименование.
Таблица «Структурное подразделение» предназначена для хранения всех структурных подразделений. Таблица «Структурное подразделение» связана с таблицей «Классификация подразделений», так как «Классификация подразделений» является классификацией. Таблица включает поля: код подразделения, наименование, краткое наименование, шифр, руководителя, описание, статус существования подразделения, статус курирования (курируется подразделение в данный момент или нет) и код классификации.
Таблица «Внутреннее подразделение» предназначена для хранения внутренней структуры основного подразделения. Таблица «Внутреннее подразделение» связана с таблицей «Структурное подразделение», так как «Структурное подразделение» является справочником основных подразделений. Таблица включает поля: код внутреннего подразделения, наименование, краткое наименование, шифр, руководителя, описание, статус существования подразделения и код подразделения.
Таблица «Пользователь» предназначена для хранения всех пользователей системы. Таблица включает поля: код пользователя, фамилия, имя, отчество, логин, пароль, e-mail, телефон.
Таблица «Вид документа» предназначена для хранения типов документов. Включает в себя поля: код вида и наименование.
Таблица «Документ» предназначена для хранения всех документов. Таблица «Документ» связана с таблицей «Вид документа», так как «Вид документа» является классификацией видов документов. Таблица включает поля: код документа, номер, дату принятия, название, имя файла (документа), расширение файла (документа), дата загрузки, код вида и код пользователя.
Таблица «Приказ» предназначена для загрузки приказов по изменению структуры, к которым привязывается история. Таблица «Приказ» связана с таблицей «Пользователи», так как к пользователю привязывается приказ. Таблица включает поля: код приказа, номер, дату принятия, название, название файла (документа), расширение файла (документа), код пользователя.
Таблица «История изменений» предназначена для фиксирования изменений в структуре. Таблица «История изменений» связана с таблицами «Структурное подразделение», «Внутреннее подразделение», «Приказ». Связь со «Структурным подразделением» и «Внутренним подразделением» является привязкой изменений к подразделениям. Связь с «Приказом» является привязкой изменений к приказу. Таблица включает поля: код истории, описание, дата создания, дата удаления, код подразделения, код внутреннего подразделения, код приказа.
Таблица «Должность» предназначена для хранения должностей ректората. Таблица включает поля: код должности и наименование.
Таблица «Доверенность» предназначена для хранения доверенностей (по доверенности назначается проректор на должность). Таблица «Доверенность» связана с таблицами «Пользователь» и «Должность». Связь с «Пользователем» является привязкой пользователя к доверенности. Связь с «Должностью» является привязкой должности к доверенности. Таблица включает поля: код доверенности, фамилию, имя, отчество, дату начала (курирования подразделений), дату завершения (курирования подразделений), имя файла (документа), расширение файла (документа), статус доверенности, код должности и код пользователя.
Таблица «Подчинённость» предназначена для отображения информации о том, какой проректор руководит каким-либо подразделением. Таблица «Подчинённость» связана с таблицами «Доверенность» и «Структурное подразделение». То есть к подчиненности привязываются подразделение и доверенность подразделений поля: код подчиненности, код подразделения, код доверенности.
Для того чтобы перейти к реализации системы, необходимо построить физическую модель данных (рис. 2) [6].
Рис. 2. Физическая модель модуля «Структура вуза» (дата логический уровень)
В качестве СУБД была выбрана MySQL, поскольку она обладает хорошей скоростью работы, надежностью, гибкостью, обладает поддержкой скриптового языка программирования PHP и является полностью бесплатной.
Помимо способа организации данных, также нельзя не сказать о совместимости со смежными системами. Планируется не интегрировать в текущую систему, а разработать отдельным модулем и осуществить переход на него с официального сайта.
Еще одним из главных требований является контроль, обновление и восстановление данных. Для обеспечения контроля и восстановления в системе будет пользователь администратор, который будет отслеживать работу системы, производить резервное копирование и архивирование данных. Обновление системы будет происходить по необходимости, заниматься обновлением будет секретарь ученого совета.
Выводы
В результате была построена информационная модель будущего модуля, как на логическом уровне, так и на физическом с учетом типов данных будущей системы. Был установлен порядок контроля, обновления и восстановления системы. Было предложено решение по совместимости со смежными системами. Дальнейшая работа над проектом будет посвящена реализации проекта – разработки интерфейса и функционала системы, тестирования и внедрения.