Процессный подход в управлении. Взять процессный подход. Выпускная квалификационная работа бакалавра проект разработки и внедрения системы управления образовательным процессом коммерческого
 Скачать 3.03 Mb.
|
|
ГЛАВА 2. РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ УПРАВЛЕНИЯ СОВМЕСТНОЙ ОБРАЗОВАТЕЛЬНОЙ ДЕЯТЕЛЬНОСТЬЮ И ПЛАНА ЕЁ ВНЕДРЕНИЯ 2.1. Определение требований к разрабатываемой системе управления 2.1.1. Выработка требований для информационной системы В ходе проекта разрабатывается система управления совместной обра- зовательной деятельностью, состоящая из трех компонентов: выбранной су- ществующей информационной системы, описанной формализованной моде- ли процессов «Как должно быть» и задокументированных правил работы с данной системой управления. Именно информационная система является ос- новой разрабатываемой системы управления, так как с ней напрямую будут взаимодействовать сотрудники компании. Поэтому к её выбору необходимо отнестись с наибольшим вниманием, опираясь в процессе на требования за- интересованных сторон. Для определения требований к информационной системе были выделе- ны следующие группы заинтересованных сторон: компания-заказчик АО «РОББО», пользователи системы, т.е. сотрудники АО «РОББО», и бюджет- ное образовательное учреждение, на базе которого проводятся курсы робото- техники. Требования к информационной системе целесообразно разделить на функциональные, и нефункциональные. Первые описывают то, что именно должна делать система. Для функциональных требований важно сформиро- вать образ будущей системы, показать, что конкретно должно выполняться в системе с точки зрения данных, с точки зрения поведения и с точки зрения функциональности [17]. Нефункциональные требования к ИС описывают то, как система должна осуществлять свою деятельность и какими свойствами обладать. К ним относятся требования к надежности и безотказности систе- мы, к её способности изменяться и быть гибкой, а также к скорости работы. Примерами нефункциональных требований могут служить различные огра- ничения, например, существующие правила компаний, или требования к ин- терфейсу и дизайну. В эту же категорию попадают требования к наличию 29 лицензий или других юридических документов, а также требования к прове- дению тестирования выбранной ИС. В ходе работы над выбором информационной системы совместно с за- интересованными сторонами проекта были выявлены требования, как функ- циональные, так и нефункциональные. Работая с требованиями, необходимо их фиксировать, чтобы в процессе работы над проектом не возникало разно- гласий, и была возможность проверить их выполнение уже после выбора ин- формационной системы. Кроме того, важно учитывать, что для эффективной работы с требованиями каждое из них должно удовлетворять определенным критериям качества, в частности: однозначность, выполнимость, понятность, проверяемость [17]. Результат выявления функциональных и нефункцио- нальных требований заинтересованных сторон к ИС представлен в табл. 2.1. Таблица 2.1 Требования заинтересованных сторон к ИС Группа заинтересо- ванных сторон Функциональные требования к ИС Нефункциональные требо- вания к ИС Компания (Заказчик) 1. ИС должна фиксировать про- деланную работу, а также пока- зывать те действия, которые ещё не сделаны. 2. ИС должна предоставлять возможность передачи элек- тронных документов. 3. ИС должна предоставлять возможность управления про- цессами, включая контроль над их выполнением. 4. ИС должна предоставлять возможность одновременной работы пользователей над зада- чами. 1. Стоимость использования ИС не должна превышать 5000 руб. в месяц. 2. ИС должна быть надежной и обеспечивать бесперебой- ную и круглосуточную работу с ней. 3. Требуется разработанный регламент, определяющий ро- ли и ответственность для пользователей ИС. 4. Количество одновременно работающих пользователей - не менее 7 [18]. 30 Продолжение табл. 2.1. Группа заинтересо- ванных сторон Функциональные требования к ИС Нефункциональные требо- вания к ИС Бюджетное образова- тельное учреждение (Партнер заказчика) Разрабатываемая системадолж- на удовлетворять требованиям ФГОС, а именно: «информационно- образовательная среда образова- тельного учреждения должна обеспечивать возможность осуществлять в электронной форме следующие виды деятельности: - планирование образовательно- го процесса; - размещение и сохранение ма- териалов образовательного про- цесса; - фиксацию хода образователь- ного процесса» [1]. 1. ИС должна обеспечивать безопасность хранения дан- ных и различные уровни дос- тупа к информации. 2. По требованиям ФГОС функционирование инфор- мационной образовательной среды должно обеспечивает- ся средствами информацион- но-коммуникационных тех- нологий и квалификацией работников, ее использующих и поддер- живающих [1]. Поэтому не- обходимо не только настро- ить систему, но и обучить сотрудников работать с ней, создав для них понятные правила. Сотрудники компании- заказчика (Пользовате- ли) 1. ИС должна включать перечень процессов, которые выполняют сотрудники. 2. ИС должна помогать выпол- нять ежедневные обязанности сотрудников. 3. ИС должна позволять отсле- живать статусы по текущим за- дачам. 1. ИС должна иметь понят- ное и удобное управление. 2. Должны быть разработаны правила работы с ней. 3. ИС должна быть доступна на разных устройствах и платформах (ПК/мобильный телефон, Android/Apple). Приказом Минобрнауки России утверждено, что при реализации обра- зовательной программы начального общего образования для участников об- разовательного процесса, в том числе преподавателей, должны создаваться 31 условия, обеспечивающие возможность эффективного управления образова- тельным учреждением с использованием информационно- коммуникационных технологий [1]. Таким образом, создание и внедрение автоматизированной системы управления образовательным процессом спо- собствуют исполнению данного приказа. Но при этом, необходимо выполне- ние требований ФГОС, перечисленных выше, В результате работы с требованиями заинтересованных сторон было принято решение выбрать информационную систему, которая бы представ- ляла собой веб-сервис, основанный на канбан-методе. Это позволит выпол- нить требования по управлению процессами, включая фиксацию проделан- ной работы, контроль над выполнением процессов и предоставление инфор- мации о том, что необходимо сделать. При правильной настройке такой сер- вис способен помочь сотрудникам контролировать выполнение ежедневных задач и предоставлять карточки процессов, которые необходимо выполнить. Для бюджетного образовательного учреждения важно наличие возможности планировать процессы, размещать и сохранять материалы. В веб-сервисах, использующих канбан-метод, это возможно сделать, прикрепляя электрон- ные документы к карточкам на канбан-доске. Работая с карточками сотруд- ники будут наглядно видеть, как идет образовательный процесс, т.е. следить за ходом его выполнения. Таким образом, выбор в качестве информационной системы веб-сервиса, работающего по методу канбан, позволит выполнить функциональные требования заинтересованных сторон. Не все веб-сервисы подойдут для целей проекта, так как нефункцио- нальные требования очень разнообразны. Как видно из них, помимо выбора ИС, ставится задача разработки регламентов, описывающих правила работы с ней и распределение ролей и ответственности пользователей. Нефункцио- нальные требования, которые относятся к системе, а не к регламентам, по- служат критериями для выбора наиболее подходящего веб-сервиса, который станет основой будущей системы управления образовательным процессом. При этом выбранный веб-сервис должен предоставить возможность для вне- 32 сения в него необходимых процессов и управления ими, включая контроль за их выполнением, а также соответствовать всем остальным функциональным требованиям и требованиям ФГОС. Таким образом, на основе нефункцио- нальных требований выработаны следующие критерии для выбора информа- ционной системы, основанной на канбан-методе: стоимость; обеспечение круглосуточного бесперебойного доступа; удобность интерфейса и управления; доступность на различных устройствах и платформах; безопасность и наличие различных уровней доступа (к просмотру данных, к управлению процессами и внесению изменения). Прежде чем управлять процессами в ИС, их вначале необходимо вы- явить и описать, создав формализованную модель «Как должно быть». 2.1.2. Определение требований к нотации для описания бизнес-процессов Для того чтобы перейти к созданию модели бизнес-процессов, необхо- димо выбрать нотацию, соответствующую требованиям заинтересованных сторон и целям проекта. Под нотацией подразумевается набор правил и ус- ловных обозначений, которые приняты и используются для графического описания процессов [19]. В данном вопросе важно учесть требования не только заказчика, но и команды, и руководителя проекта, так как они напря- мую будут работать с нотацией и далее использовать в проекте результат мо- делирования. Требования описывают, какие функции, а также с соблюдением каких условий должны выполняться при решении поставленной задачи [20]. В данном случае, требования к нотациям описывают те возможности, кото- рые она может предоставить. Чтобы понимать модель процессов в выбранной нотации, а также предлагать вносить изменения, руководитель проекта должен понимать, как она устроена. Поэтому первое требование и соответственно критерий выбора нотации - простота её освоения. Для всех нотаций существует специализиро- 33 ванное программное обеспечение, доступность которого также является важ- ным требованием. В проекте выявляются и описываются процессы, которые впоследствии будут откорректированы в соответствии с требованиями заин- тересованных сторон и внедрены в информационную систему для дальней- шего управления ими. Поэтому важно, чтобы нотация позволяла произвести легкую и быструю интеграцию описанных процессов в ИС без специальной доработки. Из этого следует, что одним из критериев выбора будет возмож- ность пошагового описания процессов. Пошаговое представление позволит при настройке системы легко по очереди перенести все задачи в ИС для дальнейшего управления ими. Некоторые стандарты описания процессов по- зволяют производить их декомпозицию - разделять целое на отдельные со- ставные части, переходя от сложного к простому. Данная возможность осо- бенно важна на этапе внесения корректировок в модель, так как нужно ви- деть картину целиком, чтобы выявить неточности и причины ошибок. Воз- можность декомпозиции является важным требованием к выбираемой нота- ции. В лучшем случае - это должна быть автоматическая декомпозиция сред- ствами программного обеспечения, поддерживающего нотацию. В худшем - декомпозиция процессов, производимая отдельным документом. После по- строения модели, необходимо будет обсудить её с заказчиком и получить одобрение. При этом важно, чтобы нотация была наглядна и проста для по- нимания даже не профессионалам в процессном моделировании. Поэтому, последнее требование - простота восприятия моделей, описанных в нотации. Таким образом, выработаны следующие требования, которые выступят в роли критериев при выборе нотации: простота освоения нотации; доступность программного обеспечения; возможность пошагового описания процессов; возможность декомпозиции; простота восприятия полученных моделей. 34 Выбранная нотация не только призвана способствовать созданию кор- ректной модели «Как должно быть», но и будет использоваться при настрой- ке информационной системы. Поэтому для неё выделено две задачи: 1) описание процессов верхнего уровня для управляющего персонала; 2) описание процессов нижнего уровня с декомпозированными зада- чами для персонала, исполняющего их. Для достижения поставленных задач возможен выбор и дальнейшее описание процессов в нескольких нотациях. 2.1.3. Определение требований к программному обеспечению для описания бизнес-процессов Программное обеспечение для описания моделей процессов имеет большое значение для специалиста, который напрямую будет работать с ним и заниматься описанием бизнес-процессов, поэтому необходимо в первую очередь учитывать его требования, опыт использования различного ПО и ре- комендации. Важным критерием выбора также является поддержка програм- мой всех необходимых инструментов и функций для работы в выбранной но- тации и то, что она позволяет применить все те сильные стороны и возмож- ности нотации, которые представляют ценность для задач проекта. Принимая во внимание вышесказанное, было выделено три основных требования к программному обеспечению для описания бизнес-процессов: поддержка работы с выбранной нотацией, доступность программы и личные предпочтения специалиста по моделированию. 2.2. Выбор нотации методом квалиметрической свертки Ранее уже были выделены 3 наиболее известные нотации, которые подходят для целей проекта, т.е. для описания образовательных процессов. Характеристика, а также основные преимущества и недостатки нотаций были рассмотрены в первой главе. Теперь, опираясь на установленные критерии, выберем наиболее подходящую для целей проекта нотацию. 35 Приняв во внимание мнение специалиста по моделированию, а также задачи, которые ставятся перед нотацией, каждому критерию присвоен весо- вой коэффициент, обозначающий его относительную важность. Первосте- пенной задачей является внедрение полученной модели процессов в ИС. По- этому «возможность пошагового описания процессов» является наиболее важным критерием выбора. «Возможность декомпозиции» также важна, так как позволяет выполнить вторую задачу, которая ставится перед нотацией, - описание процессов верхнего уровня. «Простота восприятия» является наи- менее важным критерием, так как описанная графическая модель не предпо- лагает использование её широким кругом лиц. Если сложить все весовые коэффициенты, указанные в квадратных скобках, то в сумме они должны давать единицу. Результаты распределения весовых коэффициентов приведены ниже: простота освоения нотации — [0,15]; доступность программного обеспечения — [0,15]; возможность пошагового описания процессов — [0,4]; возможность декомпозиции — [0,2]; простота восприятия полученных моделей — [0,1]. Для осуществления выбора нотации был использован метод квалимет- рической свертки. Для каждого критерия определяется наилучшее (1) и наи- худшее (0) значения. Для критериев будет производиться субъективная оцен- ка, так как нельзя численно определить, например, простоту освоения нота- ции. После того, как все критерии получат оценки, для каждой нотации рас- считывается комплексная оценка (КО) по формуле: КО где k – критерий выбора, с первого по пятый, Ves k – весовой коэффициент k- го критерия, Otn k – относительная оценка k-го критерия. 36 Для разрабатываемого проекта все расчеты производятся по трем раз- личным нотациям: IDEF0, BPMN 2.0 и ARIS eEPC. Для каждой из них будет получено комплексное значение оценки от нуля до единицы. Нотация IDEF0 удобна для описания сложных процессов и позволяет декомпозировать их на более простые. Также она позволяет учесть их «вхо- ды» и «выходы», требуемые механизмы и управляющие воздействия. Она отлично подходит для описания процессов высокого уровня декомпозиции и для выявления нестыковок «входов» и «выходов» процессов. Характеристика нотации IDEF0, а также оценка по критериям представлена в таблице 2.2. Таблица 2.2 Вычисление комплексной оценки нотации IDEF 0 Критерий: Относит. оценка: Обоснование: Комплексная оценка: Простота освоения нотации [0,15] 0,9 Нотация имеет простые правила ра- боты с ней, а также в ней всего 2 типа сущностей (блок и стрелка) 0,135 Доступность про- граммного обеспе- чения [0,15] 0,9 Существует большое количество как платных, так и бесплатных про- грамм для работы с нотацией 0,135 Возможность пошагового описа- ния процессов [0,4] 0,2 Для того, чтобы получить пошагово все процессы, необходимо много- кратно перемещаться по различным уровням декомпозиции 0,08 Возможность де- композиции [0,2] 1 Нотация предоставляет возмож- ность декомпозировать процессы до необходимого уровня 0,2 Простота воспри- ятия полученных моделей [0,1] 0,9 Благодаря ограничению количества блоков на одном уровне и простым правилам, модели в данной нотации легки для восприятия 0,09 ИТОГО: 0,135 + 0,135 + 0,08 + 0,2 + 0,09 = 0,64 37 Нотация BPMN 2.0 позволяет выстраивать процессы, располагая их все «по цепочке» на общей схеме. Она отлично подходит для целей описания процессов низкого уровня декомпозиции. Кроме того, нотация позволяет на- глядно увидеть все документы и артефакты, которые передаются в описы- ваемых процессах. Характеристика нотации BPMN 2.0, а также оценка по критериям представлена в таблице 2.3. Таблица 2.3 Вычисление комплексной оценки нотации BPMN 2.0 Критерий: Относит. оценка: Обоснование: Комплексная оценка: Простота освоения нотации [0,15] 0,7 Нотация имеет интуитивно понятные правила работы с ней, но в ней присут- ствует четыре категории элементов, ко- торые также подразделяются на типы 0,105 Доступность про- граммного обеспе- чения [0,15] 0,7 Существует достаточное количество как платных, так и бесплатных про- грамм для работы с нотацией 0,105 Возможность пошагового описа- ния процессов [0,4] 1 Даже самый сложный процесс, вклю- чающий в себя большое количество ша- гов, можно описать на одном уровне в порядке их выполнения 0,4 Возможность де- композиции [0,2] 0,1 Нотация не предоставляет возможность автоматически декомпозировать про- цессы, все описание происходит на од- ном уровне. Декомпозировать процесс можно только отельным документом 0,02 Простота воспри- ятия полученных моделей [0,1] 0,7 Ограничения по количеству процессов и других элементов на схеме нет, но модели остаются простыми для воспри- ятия, благодаря интуитивно понятным правилам и небольшому количеству ка- тегорий элементов 0,07 ИТОГО: 0,105 + 0,105 + 0,4 + 0,02 + 0,07 = |