CC BY
60
W 00465 С.В. Куликова, А.А. Круглов
DOI: http://dx.doi.org/10.21686/1818-4243-2018-1-83-92
Российский экономический университет им. Г.В. Плеханова,
Москва, Россия
Разработка метода непрерывного совершенствования услуг с использованием инструментов Business Intelligence *
Цель исследования — разработка метода непрерывного совершенствования услуг с использованием инструментов Business Intelligence.
Материалы и методы: использованы материалы о концепции Цикла Деминга, методы и технологии Business Intelligence, методология Agile и SCRUM.
Результаты. В статье рассматривается проблема непрерывного совершенствования услуги и предлагается вариант решения с использованием методов и технологий Business Intelligence. В данном случае назначение этой технологии заключается в том, чтобы решить и принять окончательное решение касательного того, что именно требует улучшения в текущей организации услуги. Иными словами, Business Intelligence помогает менеджеру продукта увидеть то, что скрыто от «человеческого глаза» на основании полученных и обработанных данных. Разработка метода основана на концепции Цикла Деминга и на методологиях Agile и SCRUM.
В статье описываются основные этапы разработки метода с учетом вида деятельности предприятия. Для выявления узких мест и обоснования необходимости их устранения и в целом для непрерывного совершенствования услуги, необходимо полное построение системы Business Intelligence на предприятии. Этот процесс представлен в нотации DFD. В статье представлена схема выбора подходящей гибкой методологии. Предложена концепция решения заявленных задач, включающая в себя методику выявления проблем с помощью технологий Business Intelligence, разработку части системы для устранения проблем и анализ результатов внедренных изменений. Приведено техническое описание реализации проекта. Заключение. По итогам работы авторов была сформирована концепция метода постоянного совершенствования услуги с использованием технологии Business Intelligence, учитывающая специфику предприятий, предлагающих SaaS-решения. Также было установлено, что при использовании данного метода ре-
комендуемой методологией разработки является SCRUM. Результатом данной научной работы является метод постоянного улучшения ИТ-услуг с использованием Business Intelligence для предприятий, предлагающих SaaS-решения, который решает выявленные проблемы в существующих методах непрерывного совершенствования. Представленный в работе метод состоит из следующих шагов:
— анализ существующего состояния услуги и выявление узких мест;
— анализ возможных причин возникновения проблем;
— формирование требований к совершенствованию услуги;
— разработка части системы, включающая в себя устранение проблем;
— анализ полученных результатов внедренных изменений;
— определение новых измеряемых критериев и сбор данных. Разработанный метод был использован на предприятии OOO «Solomoto». В ходе практической апробации данного метода была устранена выявленная проблема обучающих руководств в SaaS-платформе Solomoto. Помимо этого, были выявлены ряд положительных эффектов от внедрения данного метода на предприятии. В их число входят следующие:
— увеличение качества формирования требований;
— улучшение реакции на потребности бизнеса;
— уменьшение затрат и негативного влияния на реализацию изменений;
— повышение качества информации о состоянии услуг, а также улучшение различных метрик.
— повышение качества работы персонала;
— повышение конкурентоспособности предприятия, за счет непрерывного улучшения и поддержания услуги в актуальном состоянии.
Ключевые слова: совершенствование услуг, услуга информационных технологий, Business Intelligence, BI, SaaS, Agile, SCRUM.
Svetlana V. Kulikova, Alexander A. Kruglov
Plekhanov Russian University of Economics, Moscow, Russia
Development of a method of continuous improvement of services using the Business Intelligence tools
The purpose of the study was to develop a method of continuous improvement of services using the Business Intelligence tools. Materials and methods: the materials are used on the concept of the Deming Cycle, methods and Business Intelligence technologies, Agile methodology and SCRUM.
Results: the article considers the problem of continuous improvement of services and offers solutions using methods and technologies of Business Intelligence. In this case, the purpose of this technology is to solve and make the final decision regarding what needs to be
improved in the current organization of services. In other words, Business Intelligence helps the product manager to see what is hidden from the "human eye" on the basis of received and processed data. Development of a method based on the concept of the Deming Cycle and Agile methodologies, and SCRUM.
The article describes the main stages of development of method based on activity of the enterprise. It is necessary to fully build the Business Intelligence system in the enterprise to identify bottlenecks and justify the need for their elimination and, in general, for continuous
* Работа выполнена при финансовой поддержке РФФИ (проект № 16-07-01062 «Разработка методов и средств инжиниринга предприятий на основе интеллектуальных технологий»).
improvement of the services. This process is represented in the notation of DFD. The article presents a scheme for the selection of suitable agile methodologies.
The proposed concept of the solution of the stated objectives, including methods of identification of problems through Business Intelligence technology, development of the system for troubleshooting and analysis of results of the introduced changes. The technical description of the project is given.
Conclusion: following the work of the authors there was formed the concept of the method for the continuous improvement of the services, using the Business Intelligence technology with the specifics of the enterprises, offering SaaS solutions. It was also found that when using this method, the recommended development methodology is SCRUM. The result of this scientific research is the continuous improvement of IT services, using Business Intelligence for enterprises, offering SaaS solutions, which solves the problems, identified in the existing methods of continuous improvement. Proposed method consists of the following steps:
— analysis of the current status of the service and identification of bottlenecks;
— analysis of possible causes of problems;
— formation of requirements to improve services;
— development of the part of the system, including troubleshooting;
— analysis of the results of the implemented changes;
— definition of new measurable criteria and data collection.
The developed method was used at the enterprise Ltd "Solomoto". In the course ofpractical testing of this method the identified problem of tutorials in SaaS platform Solomoto was eliminated. In addition, they identified several positive effects from the implementation of this method in the enterprise. They include the following:
— increase in the quality of requirements 'formation;
— improving response to business needs;
— reduce costs and negative impact on the implementation of changes;
— improving the quality of information on the state of services and the improvement of various metrics;
— improving the quality of work of staff;
— improving the competitiveness of enterprises through continuous improvement and maintaining the service up to date.
Keywords: service improvement, information technology service, Business Intelligence, BI, SaaS, Agile, SCRUM.
Введение
В последнее время, SaaS особенно актуален в инновационных предприятиях и в инновационных отраслях экономики. И для такого рода предприятий остро стоит вопрос об актуальности и своевременности предоставляемых услуг. Поэтому необходимо понимать и учитывать, что именно и в какой момент стоит улучшить в предоставляемой ИТ-услуге. Для решения такого вопроса зачастую используется концепция CSI (continuous service improvement) — непрерывное улучшение (совершенствование) услуг.
В CSI особое место уделяется анализу текущей организации предоставляемой ИТ-услуги. Такого рода анализ можно провести с помощью технологии Business Intelligence (BI). В данном случае назначение BI заключается в том, чтобы решить и принять окончательное решение касательного того, что именно требует улучшения в текущей организации ИТ-услуги. Иными словами, BI помогает менеджеру продукта увидеть то, что скрыто от «человеческого глаза» на основании полученных и обработанных данных.
На текущий момент все известные подходы к CSI не учитывают специфику SaaS решений. Учет данной специ-
фики позволит избежать ряда ошибок, возникающих на этапе анализа эффективности текущей организации ИТ-услуги, что, в конечном итоге, приведет к повышению качества предоставляемой ИТ-услуги. Поэтому разработка метода непрерывного совершенствования услуг SaaS-решений, учитывая недостаточную теоретическую и практическую разработанность, особенно актуальна.
Степень научной разработанности проблематики непрерывного совершенствования ИТ-услуг. Активное использование методов совершенствования услуг, и, в частности, методов непрерывного совершенствования в различных областях современной жизни повлекло за собой развитие данных методов и в сфере информационных технологий. Методы постоянного совершенствования ИТ-услуг объединяют в себе принципы, методы, практики, относящиеся к управлению качеством, управлению изменениями и совершенствованию способностей.
В России проблемы управления качеством ИТ-услуг занимались Агафонов А.Н. [1], Денисова А.Л. [2], Козлов П.М. [3], Круглов М.Г.[4], Кушни-ков К.В. [5], Симонов Ю.Т.[6]
Значительный вклад в развитие теории управления из-
менениями внесли многие российские ученые: Анис-кин Ю.П. [7], Великий A.A. [8], Павлов В.А. [9], Широкова Г.В. [10] и др.
Если же говорить непосредственно о непрерывном совершенствовании ИТ-услуг, то в России, на данный момент, эта проблематика изучена недостаточно, однако известны работы следующих ученых: Доронина Ю.В. [11], Туша-вин В.А. [12], Чумаков Р.Е. [13] Однако, несмотря на то, что в их работах рассмотрены проблемы совершенствования услуг, не учитывается вопрос непрерывности.
Данная проблема более популярна среди зарубежных ученых, в их числе Голдратт Э.М. [14,15] и многие другие.
Разработки вышеуказанных авторов имеют большое теоретическое и практическое значение. Однако в их работах не рассмотрены вопросы применения методов непрерывного совершенствования для SaaS.
Формирование концепции метода непрерывного совершенствования услуг
Как было сказано выше, SaaS имеет ряд особенностей:
— приложение приспособлено для удаленного использования;
— одним приложением пользуется много пользователей;
— обновление и модернизация происходят оперативно и прозрачно для клиента;
— оплата взимается в виде подписок или абонентской платы;
— состоит, как правило, из несколько более мелких модулей;
— обновления и модернизация происходят регулярно;
— возможность самостоятельного расширения функционала конечным пользователем.
Так как существующие методы непрерывного совершенствования ИТ-услуги не учитывают особенности 8аа8, то ниже представлена концепция метода непрерывного совершенствования услуги, учитывающая все наиболее важные особенности 8аа8:
1. Анализ существующего состояния услуги и выявление узких мест. На данном этапе должен проводиться аналитический мониторинг всей ИТ-услуги. На основе выявленных данных, специалисты делают вывод о том, что существует некоторая проблема, которая мешает эффективной работе всей ИТ-услуги. Проблемы могут быть, как техническими, как связанными с ценообразованием, так и с дизайном, а также многим другим. И каждая из таких проблем имеет различное влияние на эффективность работы ИТ-услуги. Стоит понимать, что для объективной оценки состояния ИТ-услуг на предприятии должна быть внедрена качественная аналитика.
2. Анализ возможных причин возникновения проблем. Данный этап является наименее объективным, и как следствие, наиболее ответственным. Так как возможных причин возникновения проблем и узких мест в услуге может быть огромное множество. И не всегда можно однозначно сказать, что именно послужило причиной.
3. Формирование требований к совершенствованию услуги. Перед тем, как начать устранение выявленных проблем, необходимо выявить функциональные и нефункциональные требования, а затем описать их и передать в разработку. В рамках методологии для описания требований используются форматы пользовательских историй и сценариев использования. Непрерывное совершенствования услуг не предъявляет дополнительных условий к форме описания сценариев использования.
4. Разработка части системы, включающая в себя устранение проблем. Так как непрерывное совершенствование услуги вписывается в концепцию Цикла Деминга, то при разработке необходимо выбрать Agile методологию, в частности, это может быть Scrum или его производные. Новая рабочая версия SaaS продукта, то есть, версия с устраненной проблемой, должна быть получена каждые 1—4 недели. Данные сроки должны быть регламентированы еще до начала разработки. Стоит понимать, что, чем качественнее требования, описанные на предыдущем шаге, тем выше шанс получить наиболее качественную, выпущенную версию продукта.
5. Анализ полученных результатов внедренных изменений. Данный этап должен осуществляться параллельно с другими этапами данного метода. Так как в SaaS эффективность полученных изменений можно получить только на довольно большой выборке. Иными словами, нужно провести аналитический мониторинг и выявить реакцию конечных пользователей на внедренное изменение. Способы, используемые для анализа полученных результатов после внедрения, могут совпадать со способами и методами, используемыми на первом этапе метода непрерывного совершенствования
6. Определение новых узких мест. После того, как была выпущена новая версия ИТ-услуги и параллельно с тем, как проходит анализ полученных результатов после устранения проблемы, необходимо снова проанализировать систему на предмет выявления проблем, но стоит упомянуть, что на данном этапе из общего рассмотрения должна быть выкинута та часть, которая была внедрена в последнем релизе, так как невозможно определить ее эффективность на такой малой выборке. Иными словами, происходит формирование постоянного цикла (круга) непрерывного улучшения услуги. Именно на этом шаге формируется непрерывность улучшения.
Выявление проблем в существующем состоянии ИТ-услуги
Стоит подчеркнуть, в последнее время, SaaS особенно актуален и на рынке растет потребность в таких системах. Также стоит упомянуть, что на рынке ИТ особенно актуальны аналитические системы, позволяющие существенно повысить качество принимаемых решений [16]. Особое место среди аналитических систем занимают системы класса Business Intelligence.
Технологии BI позволяют существенно упростить процесс принятия решений и получения отчетности всеми сотрудниками компании, основываясь на возможностях многомерного (OLAP) анализа данных. Это средство многомерного интерактивного анализа больших массивов информации с помощью специализированных аналитических моделей (OLAP-кубов), а также позволяющее формировать отчеты как в табличном, так и в графическом виде [17].
На основании имеющихся данных можно выявить наиболее узкие места в SaaS
Рис. 1. Схема построения BI на предприятии
приложении и сформировать необходимые требования по их устранению. Для выявления узких мест и обоснования необходимости их устранения и в целом для непрерывного совершенствования услуги, необходимо полное построение BI на предприятии. Этот процесс представлен на Рис. 1 в нотации DFD.
В качестве источников данных могут применяться различные форматы файлов, в частности, это могут быть текстовые файлы, файлы excel, файлы xml, реляционные базы данных (MS SQL, DB2, MySQL), нереляционные базы данных (Mongo DB, eXist, CounchDB), различные метрики (Яндекс.Метрика, Google Analytics) и др. Поддерживаемые источники данных зависят только от выбранного на предприятии ETL-инструмента.
На рисунке 1 представлена полная схема построения BI. Стоит также понимать, что, если на предприятии уже построен BI, то весь процесс по анализу существующего состояния услуги и выявления узких мест сводится к построению OLAP-куба и анализу данных (аналитического мониторинга).
На этапе аналитического мониторинга проводится выявление проблем в ИТ-услуге. Это означает, что представляются ряд показателей, после чего выявляется соответствие или несоответствие услуги/ части услуги (модуля) предоставляемым требованиям. В
частности, такими показателями могут быть:
— процент ухода пользователей со страницы;
— процент негативных отзывов пользователей;
— количество пользователей;
— среднее количество просмотренных страниц за сеанс пользователем;
— количество действий для получения пользователем желаемого результата;
и др.
Данные показатели зависят от предметной области SaaS приложения и структуры самого SaaS, поэтому для каждого SaaS требуются свои показатели эффективности. Стоит упомянуть, что для аналитического мониторинга может также использоваться и Data Mining (рус. Добыча данных), использование интеллектуальных методов добычи данных позволяет еще точнее выявить проблемы, а иногда и получить совершенно неожиданные результаты. В качестве систем, предлагающих работу по добыче данных наиболее популярными, являются следующие: SPSS Modeler, Rapid Miner, SAS, а также российская система Deductor Studio. Однако, как показывает практика, к использованию Data Mining готовы далеко не все предприятия, и они обходятся только использованием OLAP.
Использование BI для анализа существующего состояния услуги и выявления узких мест может служить как для полно-
го перепроектирования услуги (или отдельного модуля), так и для ее улучшения. Использование В1 для обследования текущего состояния SaaS услуги и для выявления узких мест имеет ряд преимуществ:
1. Повышение эффективности и качества принятия решений на основании имеющихся данных.
2. Возможность получить неожиданные результаты, которые помогут реорганизовать текущий процесс.
3. Повышение доступности данных.
Несмотря на очевидные преимущества от использования В1 имеются проблемы и недостатки:
1. Возможны ошибки при интерпретации тех или иных данных, что напрямую связано с компетентностью участников построения В1.
2. Не все предприятия готовы тратиться на использование В1 для анализа качества услуги и выявления узких мест. Несмотря на рост популярности В1 многие предприятия еще не готовы внедрять В1-системы, не понимая их очевидные преимущества.
Стоит отметить, что использование В1 как метода выявления узких мест в текущей организации SaaS сервиса не предполагает использование какого-то конкретного В1-про-дукта и конкретного БТБ-инс-трумента. Но несмотря на это, выбор В1-системы является одним из важнейших элементов данного метода. Учитывая
динамичное развитие рынка данного программного обеспечения, необходимо проводить анализ их возможностей. Рекомендуется следующая критериальная база сравнения систем: возможности информационной системы (аналитические инструменты); аналитические задачи, которые позволяет решать система; категории пользователей системы. Также при выборе подходящей BI-систе-мы стоит учитывать стоимость продукта и квалификацию пользователей приобретаемой платформы. Наиболее популярными BI-системами являются следующие решения: SAS, IBM Cognos BI, Tableau, Qlikview, SAP BO, Oracle BI, а также российская система Prognoz [18]. Наиболее же популярными ETL-инструмента-ми являются следующие решения: IBM Data Stage, Pentaho Data Integration и Oracle Data Integration.
Стоит понимать, что в методе непрерывного совершенствования услуги под термином «проблемы» имеются в виду любые проблемы, которые снижают эффективность ИТ-услуги. Проблемами могут являться узкие места. Согласно определению, узкие места процесса — операции и связи, снижающие эффективность процесса, увеличивая его трудоемкость и стоимость. Узкие места обычно представляют собой дублирующиеся операции/работы, временные задержки свыше нормы, информационные петли, перегрузки отдельных элементов.
Также в число проблем ИТ-услуги входят проблемы с технической реализацией и качеством информационной системы. Также проблемы могут быть связаны с тем, что услугой пользуются не в той мере, в которой хотелось быть вендору SaaS. Это означает, что проблема — это всё, что мешает, как конечному пользователю, так и вендору SaaS, быть полностью удовлетворенными
услугой. Причин возникновения тех или иных проблем может быть огромное множество, поэтому на практике данный этап является наименее объективным, и как следствие, наиболее ответственным. Так как возможных причин возникновения проблем и узких мест в услуге, может быть огромное множество. И не всегда можно однозначно сказать, что именно послужило причиной. Зачастую выявление причин возникновения проблем сводится к опыту и компетентности специалиста, занимающегося выявлением причины. Таким специалистом может быть, как аналитик данных, как системный аналитик, как владелец продукта, так и руководитель проекта.
Наиболее благоприятным и точным является та ситуация, когда причину возникновения проблем можно обосновать с помощью проведенных расчетов. Для такого обоснования могут быть представлены ряд формул, которые определяет сам специалист, занимающейся выявлением причины.
Если же причину нельзя обосновать численно, то все сводится к опыту специалиста. Если, исходя из полученных данных, он видит, что какой-то из инструментов совсем не приносит никакой прибыли, то причин может быть множество: проблемы с дизайном, ценообразованием, сложностью функционала, слабым справочным материалом. И тут уже сам специалист должен понять, что именно из этого послужило причиной возникновения проблем, а порой причиной могла быть и совокупность факторов.
Как было сказано выше, данный этап является одним из наиболее ответственных, так как неправильное определение причины возникновения проблемы может привести к ошибкам при формировании требований. Если на устранение проблемы будут потрачены
несколько недель, а, по итогам, окажется, что выявленная проблема не решена, то, по сути, впустую будут потрачены несколько недель разработки, а, следовательно, и лишние деньги.
Разработка части системы, включающая в себя устранение проблем
Так как весь процесс непрерывного совершенствования услуги вписывается в концепцию Цикла Деминга, о которой было сказано выше, то целесообразно использовать гибкие методологии разработки (Agile). В данный момент гибкий подход к разработке набирает популярность и существует множество различных методологий, самыми популярными из которых являются Scrum, XP, Lean, AUP, Kanban. Выбор подходящей методологии зависит от ряда факторов: приоритетов бизнеса, приемлемого способа коммуникации и взаимодействия команды, количество серьезных рисков, часто ли меняются требования, что приоритетнее: скорость или качество? И многое другое.
В частности, выбор подходящей методологии может быть представлен на рис. 2.
Исходя из рис. 2, можно сделать вывод, что, так как представленный метод предполагает постоянные улучшения, то рекомендуемой методологией может быть Scrum и другие скрамоподобные методологии (Scrumban, Scrum+XP и другие).
Весь процесс Scrum можно представить на рис. 3.
Если же говорить непосредственно о формировании требований, то Agile и Scrum, в частности, в качестве форматов описания требований используются короткие User Stories (пользовательские истории) и Use cases (пользовательские сценарии).
Пользовательские истории — это краткое изложение фун-
Scrum
неважно
Kanban
рис. 2. схема выбора подходящей гибкой методологии
кциональных возможностей, реализация которых необходима для получения конкретным заинтересованным лицом пользы от программного продукта [19]. Наиболее популярный формат описания пользовательских историй включает в себя три компонента:
1. Роль пользователя. Отвечает на вопрос «Кто?»
2. Необходимое поведение (функция, действие). Отвечает на вопрос «Что делает?»
3. Выгода, ценность. Отвечает на вопросы «Зачем?», «Для чего?»
Схематично это можно представить так:
Как <роль>, я хочу <поведение> для <ценность>.
После того, как сформированы пользовательские истории, если это необходимо, они подробно расписываются в виде пользовательских сценариев. Как правило, такая необходимость существует. Сцена-
рии хорошо взаимодействуют с подготовленными ранее пользовательскими историями и покрывают их. Разработка сценариев идет совместно с дизайнером и описывает будущее поведение системы, которое нужно отразить дизайнеру. Существует множество различных вариантов формирования требований и описания пользовательских сценариев. Самыми популярными являются:
— пронумерованный список этапов, оформленный в виде таблицы;
— двухколончатая таблица Вирфс-Брока;
— свободное описание;
— табличное представление;
— полный формат Коберна;
— диаграммы деятельности, переходов состояний, вариантов использования, — последовательности;
и др.
рис. 3. scrum процессы
Выбор формата требований зависит от ряда факторов, в частности, от размера предприятия, размера и важности проекта, исторически сложившихся традиций, от пожеланий разработчиков и многого другого. Стоит учитывать, что метод непрерывного совершенствования услуги с использованием Business Intelligence для SaaS не подразумевает выбор какого-то конкретного формата описания требований.
После того, как Владелец продукта описал все необходимые требования по устранению выявленных на этапе анализа существующего состояния услуги и на этапе анализа возможных причин возникновения проблем, требования вместе с резервами спринта и проекта (бэклогами) передаются в разработку. И по итогам спринта изменения будут внедрены в систему.
Команда разработки в методе непрерывного совершенствования услуги с использованием методологии разработки Scrum обладает следующими характеристиками:
1. Они самоорганизованные. Никто (даже Скрам Мастер) не может указывать Команде, каким образом создавать Инкременты работающей функциональности из Беклога Продукта.
2. Команды Разработки — кросс-функциональны, обладают всеми навыками, необходимыми для разработки Инкремента продукта.
3. Скрам не признает никаких других должностей в Команде Разработки, кроме как Разработчик, невзирая на вид работы, выполняемой человеком; у этого правила нет исключений.
4. У Команды Разработки нет подкоманд, которые бы выполняли отдельные функции, как, к примеру, команда тестирования или бизнес-анализа.
5. Отдельные члены Команды Разработки могут вла-
деть специализированными знаниями в различных областях, однако ответственность лежит на всей Команде Разработки в целом
6. Оптимальный состав: 3—9 человек. Если в Команде Разработки менее трех человек, взаимодействие уменьшается, что приводит к снижению продуктивности. Небольшой команде может не хватить навыков в течение Спринта, что помешает завершить работу над потенциально готовым к выпуску Инкрементом продукта. Если же в Команде более девяти человек, потребуется больше усилий для координации их работы. Большие Команды Разработки создают слишком много сложностей для управления эмпирическим процессом. Роли Владельца Продукта и Скрам Мастера не учитываются при подсчете размера Команды Разработки за исключением случаев, когда они выполняют работу из Бек-лога Спринта [20].
Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:
— продолжительность спринта;
— емкость (capacity) команды;
— размер её фокус фактора (коэффициент слаженности);
— трудоемкость требований, которые будут реализованы в спринте;
— очередность выполнения задач и многое другое.
Использование Scrum для разработки особенно актуально для SaaS приложений, как на ранних стадиях, когда можно запустить проект с реализацией только минимального функционала, так и на более поздних стадиях после улучшения небольшой части проекта без разработки всех остальных ее частей.
Спринт состоит из четырех процессов:
1. Планирование. На данном этапе проверяется бэклог
и определяется, какие задачи могут быть выполнены в течение спринта, а также определяется состав команды разработки на текущий спринт.
2. Реализация. На данном этапе происходит написание кода к требуемому функционалу. В идеальной команде многие процессы происходят параллельно, например, разработчик пишет код, а тестиров-щик параллельно занимается тестированием приложения.
3. Релиз. На текущем этапе происходит развертывание реализованного функционала, после чего данный функционал становится виден конечному пользователю. Для более качественного проведения релиза на предприятии рекомендуется внедрение процесса управления релизами. Частями процесса управление релизами являются:
— библиотека эталонного программного обеспечения, в которой хранятся копии всего используемого программного обеспечения;
— запас комплектующий и документации для быстрого решения проблем с аппаратным обеспечением.
Внедрение процесса Управления релизами позволяет:
— вносить изменения в ИТ-среду без ухудшения качества обслуживания;
— уменьшить число инцидентов, вызванных несовместимостью новых систем с установленным аппаратным и программным обеспечением;
— тщательное тестирование новых ИТ-решений позволяет выявить и предотвратить потенциальные вопросы и проблемы у пользователей;
— снизить количество неконтролируемых версий программного обеспечения в ИТ-среде и тем самым предотвратить риски, связанные с использованием нелицензионного ПО;
— предотвратить утрату исходных файлов программного обеспечения.
4. Ретроспектива. Команда обсуждает спринт и возникшие при реализации проблемы. Данный процесс направление на то, чтобы решить, как можно улучшить работу в следующем спринте.
Подводя итоги, можно сказать, что метод непрерывного совершенствования услуги с использованием Business Intelligence для SaaS приложений не предъявляет требований к техническому обеспечению. Это означает, что метод не привязан ни к одному языку программирования, не предъявляет требований к серверной части приложения, ни к СУБД.
Анализ полученных результатов внедренных изменений
Данный этап должен начинаться только после того, как пройдет достаточно времени для того, чтобы можно было оценить, устранена ли проблема, повышена ли эффективность или нет. Это означает, что данный процесс должен идти независимо от того, как проходят остальные этапы данного метода непрерывного совершенствования услуг. Иными словами, данный процесс осуществляется параллельно остальным процессам. Срок, когда начинается данный процесс, должен определяться руководителем проекта и зависит от ряда факторов, в число которых входят предметная область, размер и объем изменения, какое число пользователей это затрагивает и множество других. Это делается по той причине, что в 8аа8 об эффективности полученных изменений можно узнать только на достаточной для анализа выборке. То есть, необходимо провести аналитический мониторинг реакции, как можно большего числа пользователей.
Способы, используемые для анализа полученных результатов после внедрения, могут совпадать со способами и методами, используемыми на первом этапе метода непре-
рывного совершенствования. Как правило, данный процесс выглядит следующим образом: выбирается тот же самый показатель, который учитывался на этапе анализа существующей организации услуги, но теперь этот показатель включает в себя ту выборку, которая была после внедрения изменения. Если ситуация лучше, чем была до внедрения изменений, то проводится анализ в разрезе всей услуги, как это делалось на первом этапе. Если аналитик видит, что от этого процесса не падает эффективность всей системы, то делается вывод о том, что проблема устранена, в противном случае, проблема не устранена и будет сделана еще попытка устранить ее. Идеальным является вариант, при котором эффективность ИТ-услуги не просто не падает, а, напротив, возрастает, но такое может происходить далеко не всегда, в силу различных специфических особенностей того или иного модуля, который подвергался переработке.
Если же говорить о технической реализации данного шага, то, чаще всего, он начинается непосредственно с построения ОЬЛР-куба. Однако если разработчиками были переработаны те или иные данные в базе, которые были затронуты в ОЬЛР-кубе до реализации изменений, то необходимо воспользоваться БТЬ-инструментом для преобразования данных, чтобы привести их к актуальному виду и только после этого переходить к построению ОЬЛР-куба и аналитическому мониторингу.
Параллельно с анализом полученных результатов внедренных изменений происходит возвращение на первый шаг представленного метода непрерывного совершенствования ИТ-услуги. При этом стоит отметить, что текущий этап начинается только после того, как будет выпущена новая версия ИТ-услуги и параллельно с тем, как проходит анализ полученных результатов после
устранения проблемы, необходимо снова проанализировать систему на предмет выявления проблем. Но стоит упомянуть, что на данном этапе из общего рассмотрения должна быть выкинута та часть, которая была внедрена в последнем релизе, так как невозможно определить ее эффективность на такой малой выборке. Иными словами, происходит формирование постоянного цикла (круга) непрерывного улучшения услуги. То есть, если мы выпустили новую версию продукта, то следующим шагом будет возвращение на первый шаг метода, где мы должны заново определить текущее состояние услуги и выявить все проблемы. Однако нам не стоит рассматривать только что выпущенную часть функционала услуги. Именно благодаря этому шагу формируется непрерывность совершенствования услуги.
Заключение
По итогам работы авторов была сформирована концепция метода постоянного совершенствования услуги с использованием технологии Business Intelligence, учитывающая специфику предприятий, предлагающих SaaS-решения. Также было установлено, что при использовании данного метода рекомендуемой методологией разработки является SCRUM. Результатом данной научной работы является метод постоянного улучшения ИТ-услуг с использованием Business Intelligence для предприятий, предлагающих SaaS-решения, который решает выявленные проблемы в существующих методах непрерывного совершенствования. Представленный в работе метод состоит из следующих шагов:
— анализ существующего состояния услуги и выявление узких мест;
— анализ возможных причин возникновения проблем;
— формирование требований к совершенствованию услуги;
— разработка части систе-
мы, включающая в себя устранение проблем;
— анализ полученных результатов внедренных изменений;
— определение новых измеряемых критериев и сбор данных.
Разработанный метод был использован на предприятии ООО <^о1ошо1;о». В ходе практической апробации данного метода была устранена выявленная проблема обучающих руководств в SaaS-платформе So1omoto. Помимо этого, были выявлены ряд положительных эффектов от внедрения данно-
го метода на предприятии. В их число входят следующие:
— увеличение качества формирования требований;
— улучшение реакции на потребности бизнеса;
— уменьшение затрат и негативного влияния на реализацию изменений;
— повышение качества информации о состоянии услуг, а также улучшение различных метрик.
— повышение качества работы персонала;
— повышение конкурентоспособности предприятия, за
счет непрерывного улучшения и поддержания услуги в актуальном состоянии.
В качестве дальнейшего развития предложенного метода непрерывного совершенствования услуги с использованием Business Intelligence для предприятиях, предлагающих SaaS-решения, могут быть использованы технологии Data Mining для более качественного проведения анализ текущего состояния услуги и выявления узких мест, а также для проведения анализа полученных результатов внедренных изменений.
Литература
1. Агафонов А. Н. Формирование системы управления информационными услугами : авто-реф. дис. на соиск. учен. степ. канд. экон. наук (08.00.05). Самара: Самарский госуд. эконом. университет, 2007. с. 38
2. Денисова А.Л. Качество информационных услуг: Теория и методология : автореф. дис. на соиск. учен. степ. канд. экон. наук (08.00.05) / Тамбов: Тамбовский госуд. техн. университет, 2001. с. 36
3. Козлов П. М. Разработка организационной системы управления рисками проектов информатизации машиностроительных предприятий : ав-тореф. дис. на соиск. учен. степ. канд. техн. наук (05.02.22). М.: МГТУ «СТАНКИН», 2003. с. 20
4. Круглов М. Г. Инновационный проект : управление качеством и эффективностью. М. Г. Круглов. М.: Дело, 2009. с. 333
5. Кушников К. В. Комплексная оценка качества ИТ-услуг компании : автореф. дис. на соиск. учен. степ. канд. экон. наук (08.00.05). М.: Рос. науч.-техн. центр информации по стандартизации, метрологии и оценке соответствия, 2013. с. 24
6. Симонов Ю. Т. Повышение качества ИТ-услуг в компании: автореф. дис. на соиск. учен. степ. канд. экон. наук (08.00.05). М.: Рос. науч.-техн. центр информации по стандартизации, метрологии и оценке соответствия, 2010. с. 28
7. Анискин Ю.П. Организационно-экономический механизм обновления наукоемкой продукции: диссертация доктора экон. наук (08.00.05) М.: Госуд. университет управления им. С. Орджоникидзе, 1993. с. 356
8. Великий А.А. Развитие промышленной организации на основе методологии управления изменениями : автореф. дис. на соиск. учен. степ. канд. экон. наук (08.00.05). М.: Гос. ун-т упр., 2005. с. 25
9. Павлов В.А. Методы и модели анализа и синтеза комплексов технических средств обеспечения информационного взаимодействия организационно-технических систем : авторе-
References
1. Agafonov A. N. Formirovanie sistemy upravleniya informatsionnymi uslugami : Abstract of the dissertation of Cand. Sci. (08.00.05). Samara: Samarskiy gosud. ekonom. universitet, 2007. P. 38. (In Russ.)
2. Denisova A.L. Kachestvo informatsionnykh uslug: Teoriya i metodologiya : Abstract of the dissertation of Cand. Sci. (08.00.05) / Tambov: Tambovskiy gosud. tekhn. universitet, 2001. P. 36. (In Russ.)
3. Kozlov P. M. Razrabotka organizatsionnoy sistemy upravleniya riskami proektov informatizatsii mashinostroitel'nykh predpriyatiy : Abstract of the dissertation of Cand. Sci. (05.02.22). Moscow: MGTU «STANKIN», 2003. P. 20. (In Russ.)
4. Kruglov M. G. Innovatsionnyy proekt : upravlenie kachestvom i effektivnost'yu. M. G. Kruglov. Moscow : Delo, 2009. P. 333. (In Russ.)
5. Kushnikov K. V. Kompleksnaya otsenka kachestva IT-uslug kompanii : Abstract of the dissertation of Cand. Sci. (08.00.05). Moscow: Ros. nauch.-tekhn. tsentr informatsii po standartizatsii, metrologii i otsenke sootvetstviya, 2013. P. 24. (In Russ.)
6. Simonov Yu. T. Povyshenie kachestva IT-uslug v kompanii: Abstract of the dissertation of Cand. Sci. (08.00.05). Moscow: Ros. nauch.-tekhn. tsentr informatsii po standartizatsii, metrologii i otsenke sootvetstviya, 2010. P. 28. (In Russ.)
7. Aniskin Yu.P. Organizatsionno-ekono-micheskiy mekhanizm obnovleniya naukoemkoy produktsii: Dissertation of Dr. Sci. (08.00.05) Moscow: Gosud. universitet upravleniya im. P. Ordzhonikidze, 1993. P. 356. (In Russ.)
8. Velikiy A.A. Razvitie promyshlennoy organizatsii na osnove metodologii upravleniya izmeneniyami : Abstract of the dissertation of Cand. Sci. (08.00.05). Moscow: Gos. un-t upr., 2005. P. 25. (In Russ.)
9. Pavlov V.A. Metody i modeli analiza i sinteza kompleksov tekhnicheskikh sredstv obespecheniya informatsionnogo vzaimodeystviya organizatsionno-tekhnicheskikh sistem :
ферат дис. на соиск. учен. степ. доктора технических наук : 05.25.05 М.: Рос. науч.-техн. центр информации по стандартизации, метрологии и оценке соответствия, 2016. с. 45
10. Широкова Г. В. Жизненные циклы российских предпринимательских фирм : методология исследования и основные стадии : автореферат дис. на соиск. учен. степ. доктора экономических наук : 08.00.05. СПб: С.-Петерб. гос. ун-т., 2010. с. 45
11. Доронина Ю.В. Анализ производительности и надежности автоматизированных асинхронных систем методом фазового укрупнения : автореферат дис. на соиск. учен. степ. кандидата технических наук : 05.13.07. Севастополь, 1997. с. 22
12. Тушавин В. А. Модели и методы управления качеством разрешения инцидентов при реализации информационно-коммуникационных услуг : автореферат дис. на соиск. учен. степ. кандидата технических наук : 05.02.23. СПб: С.-Петерб. гос. ун-т аэрокосм. приборостроения, 2012. с. 19.
13. Чумаков Р. Е. Технологические принципы управления сборочно-резьбообразующими процессами : автореферат дис. на соиск. учен. степ. кандидата технических наук : 05.02.08. Иркутск: Иркут. гос. техн. ун-т., 2002. с. 16.
14. Элия М. Гольдратт, Джеф Кокс. The Goal: A Process of Ongoing Improvement. М.: По-пури. 2009. с. 496.
15. Eliyahu M. Goldratt. The Haystack Syndrome: Sifting Information Out of the Data Ocean. North River Press. 2006. С. 262.
16. Тельнов Ю.Ф., Казаков В.А., Козлова О.А. Динамическая интеллектуальная система управления процессами в информационно-образовательном пространстве высших учебных заведений. Открытое образование. 2013. № 1 (96). С. 40-49.
17. Круглов А.А. BI как метод выявления узких мест в текущей организации бизнес-процессов и формирования требований к системе // IX Международная научно-практическая конференция «Инновационное развитие российской экономики» : в 6 т., М.: ФГБОУ ВО «РЭУ им. Г.В. Плеханова», 2016. С. 155-157.
18. Tadviser URL: http://www.tadviser.ru/
19. Cohn M. User stories applied: For agile Software development, 2004. с. 304
20. Сазерленд Дж., Швабер К., Скрам гайд. Исчерпывающее руководство по Скраму: Правила игры, 2013. с. 17.
Сведения об авторах
Светлана Викторовна Куликова
Российский экономический университет им. Г.В Плеханова, Москва, Россия Эл. почта: Kulikova.SV@rea.ru
Александр Александрович Круглов
Российский экономический университет им. Г.В Плеханова, Москва, Россия Эл. почта: akruglov93@yandex.ru
Abstract of the dissertation of Dr. Sci.: 05.25.05. Moscow: Ros. nauch.-tekhn. tsentr informatsii po standartizatsii, metrologii i otsenke sootvetstviya, 2016. P. 45. (In Russ.)
10. Shirokova G. V. Zhiznennye tsikly rossiyskikh predprinimatel'skikh firm : metodologiya issledovaniya i osnovnye stadii : Abstract of the dissertation of Dr. Sci. : 08.00.05. SPb: S.-Peterb. gos. un-t., 2010. P. 45. (In Russ.)
11. Doronina Yu.V. Analiz proizvoditel'nosti i nadezhnosti avtomatizirovannykh asinkhronnykh sistem metodom fazovogo ukrupneniya : Abstract of the dissertation of Cand. Sci. : 05.13.07. Sevastopol', 1997. P. 22. (In Russ.)
12. Tushavin V. A. Modeli i metody upravleniya kachestvom razresheniya intsidentov pri realizatsii informatsionno-kommunikatsionnykh uslug : Abstract of the dissertation of Cand. Sci. : 05.02.23. Saint Petersburg: S.-Peterb. gos. un-t aerokosm. priborostroeniya, 2012. P. 19. (In Russ.)
13. Chumakov R. E. Tekhnologicheskie printsipy upravleniya sborochno-rez'boobrazuyushchimi protsessami : Abstract of the dissertation of Cand. Sci. : 05.02.08. Irkutsk: Irkut. gos. tekhn. un-t., 2002. P. 16. (In Russ.)
14. Eliya M. Gol'dratt, Dzhef Koks. The Goal: A Process of Ongoing Improvement. M.: Popuri. 2009. P. 496.
15. Eliyahu M. Goldratt. The Haystack Syndrome: Sifting Information Out of the Data Ocean. North River Press. 2006. P. 262.
16. Tel'nov Yu.F., Kazakov V.A., Kozlova O.A. Dinamicheskaya intellektual'naya sistema upravleniya protsessami v informatsionno-obrazovatel'nom prostranstve vysshikh uchebnykh zavedeniy Otkrytoe obrazovanie. 2013. No. 1 (96). P. 40-49. (In Russ.)
17. Kruglov A.A. BI kak metod vyyavleniya uzkikh mest v tekushchey organizatsii biznes-protsessov i formirovaniya trebovaniy k sisteme // IX Mezhdunarodnaya nauchno-prakticheskaya konferentsiya «Innovatsionnoe razvitie rossiyskoy ekonomiki» : 6 vol., Moscow: FGBOU VO «REU im. G.V. Plekhanova», 2016. P. 155-157. (In Russ.)
18. Tadviser URL: http://www.tadviser.ru/. (In Russ.)
19. Cohn M. User stories applied: For agile Software development, 2004. P. 304.
20. Sazerlend Dzh., Shvaber K., Skram gayd. Ischerpyvayushchee rukovodstvo po Skramu: Pravila igry, 2013. P. 17. (In Russ.)
Information about the authors
Svetlana V. Kulikova
Plekhanov Russian University of Economics,
Moscow, Russia
E-mail: Kulikova.SV@rea.ru
Alexander A. Kruglov
Plekhanov Russian University of Economics,
Moscow, Russia
E-mail: akruglov93@yandex.ru
