Определение места проектируемой задачи в списке задач и ее описание
Для устранения выявленных затруднений в работе старшего администратора необходимо использовать средства автоматизации. Для выбора таких средств определим необходимые формы отчетности.
В процессе мониторинга взаиморасчетов используются следующие основные отчеты:
Отчет по продажам за период,
Отчет по оплатам за период,
Отчет по динамике задолженности,
Реестр путевок,
Отчеты движений документов по регистрам,
Общий отчет по долгам.
Мониторинг взаиморасчетов гостей ведется по полному счету гостя, который детализирует информацию в разрезе лицевого счета, что не приемлемо в случаях, когда у гостя несколько лицевых счетов. Данный способ является очень неудобным, медлительным и зачастую недостоверным.
Рассмотрим случай, когда старшему администратору необходимо проконтролировать выезд «массового заезда». Для этого необходимо проверить взаиморасчеты по каждому выезжающему. Скорость проверки зависит от массы нюансов, таких например как:
Период проживания.
Способ оплаты.
Количество потреблённых дополнительных услуг.
Количества предыдущих размещений.
Возникают случаи, когда необходима корректировка начислений, что существенно увеличивает время проверки. Архитектура системы устроена так, что начисления по услугам проживания проходят в разрезе структурного подразделения и отражены одним документом – «Ночной аудит». Отсюда следует, что время корректировки начислений зависит от загруженности подразделения, по которому формируется ночной аудит.
Практика показывает, что на проверку состояния взаиморасчетов и корректности начислений уходит от 30 минут до 2-3 часов. Среднее количество гостей на выезд ежедневно составляет 10-15 человек. Проверка и корректировка взаиморасчетов такого количества гостей может занять у старшего администратора от 5 до 45 часов. Ни один администратор с таким потоком не способен справиться, что ведет к необходимости большего количества сотрудников, что в свою очередь, влечет за собой существенные финансовые затраты.
Так как вид проверки и корректировки – ручной, то весь процесс занимает продолжительное время и результат может являться недостоверным.
В результате автоматизации работы старшего администратора клиент и руководство имеет точнейшие сведения о состоянии взаиморасчетов, а также время работы по каждому гостю.
Для автоматизации необходимо использовать персональные компьютеры, принтеры, а также специальное программное обеспечение, а так же локальную вычислительную сеть.
Рассчитаем ожидаемый эффект от автоматизации (таблица 2).
Таблица 2 Расчет эффекта автоматизации
Процесс |
Время, затрачиваемое при ручной проверке/ мин. |
Время, затрачиваемое после автоматизации/ мин. |
Просмотр необходимой отчетности |
20 |
5-10 |
Корректировка взаиморасчетов |
30-180 |
5-15 |
Оповещение клиента\разработчика программного обеспечения |
10 |
1 |
Таким образом, при существующей системе проверке и корректировке основные процессы занимают около 30 минут. При автоматизации это время сокращается до 5-15 минут. Кроме того, основными достоинствами автоматизации процесса проверки и исправления взаиморасчетов будут:
возможность отправить сообщения клиентам;
структуризация данных;
более оперативная обработка данных;
выдача результатов в удобной форме на принтер и экран;
легкое корректировка данных;
сокращение времени для оформления отчетности.
Для построения функциональной модели проектируемой системы будет использоваться AllFusion Process Modeler (Ramus).
Ramus основной инструмент бизнес-аналитиков в проектах по построению или реорганизации систем управления предприятием. К таковым могут относиться: проекты по реинженирингу бизнес-процессов, проекты внедрения процессного управления, проекты построения системы менеджмента качества, проекты построения системы управления знаниями и т.п.
Основными возможностями Ramus являются:
Моделирование процессов (согласно методологий IDEF0 и DFD);
Разработка систем классификации и кодирования предприятия с внутренними перекрёстными связями, которая также тесно увязывается и с моделями процессов;
Формирование отчётности по моделям и системе классификации, в том числе и отчётности в форме такой регламентирующей документации как должностные инструкции и регламенты процессов;
Генерация сайта, который призван обеспечить доступ к данным моделей процессов, системы классификации и кодирования а также к разнообразнейшей отчётности через веб-интерфейс.
Ramus имеет редактор диаграмм IDEF0 и DFD эргономичность которого находится на уровне не ниже чем у аналогичных продуктов имеющих схожие редакторы. Это проявляется в более лёгкой и быстрой навигации по модели, в более «умном» поведении объектов диаграмм, в поддержке шаблонов диаграмм, в возможности быстрого исправления допущенных ошибок, в том числе и в возможности отмены действий.
Так как, модели процессов реальных предприятий могут содержать многие тысячи разнообразнейших объектов (документы, персонал, функции и т.д.), то в Ramus предусмотрена возможность упорядочено хранить информацию об этих объектах в виде системы классификаторов. Классификация объектов значительно упрощает поиск и обработку информации об объектах модели, а так же и об объектах непосредственно на диаграммах процессов не представленных, но, так или иначе, относящихся к процессам предприятия. Каждый элемент системы классификации, кроме собственно названия, может иметь дополнительные атрибуты, в которых можно упорядочено хранить разнообразнейшую информацию об объекте.
Стоит отметить, что для создания качественной и информативной отчётности по модели, крайне необходимо, чтобы вся информация проекта содержалась упорядочено в виде системы классификации.
Для генерации отчётности в Ramus присутствует редактор отчётности. Наличествует поддержка шаблонов отчётов в формате XML которые могут быть экспортированы из файла или импортированы в файл.
Совокупность моделей, классификаторов, матричных проекций и отчётов имеющих отношение к одному и тому же предприятию в дальнейшем будем называть Проект.
Просмотр всей информации Проекта может быть осуществлён через веб-браузер . Для этого разработан веб-сервер который выводит информацию Проекта в виде набора HTML страниц, или же, попросту говоря, в виде сайта. Это существенно упрощает использование и развёртку Ramus, так как избавляет от необходимости установки клиентской версии Ramus на АРМах пользователей которые имеют доступ только на чтение информации Проекта. Всей или некоторой информации Проекта, что определяется настройками прав доступа.
К любому элементу системы классификации и кодирования можно прикреплять файлы, которые будут доступны для скачивания с сайта Проекта. Использование технологии Java при реализации программных модулей, позволяет использовать Ramus под разными видами операционных систем и аппаратных платформ (MS Windows, Linux, Mac OS, и т.д.…).
Ramus может использоваться в файловом (локальном) и сетевом вариантах. Сетевая версия Ramus позволяет распределять доступ пользователей к данным. Сетевая версия Ramus использует стандартизированные протоколы обмена данными, что позволяет интегрировать Ramus с другими системами. Но и без использования сетевой версии можно разделить работу над Проектом между несколькими разработчиками путём использования функции расщепления Проекта.
В Ramus включена поддержка нескольких языков графического интерфейса пользователя. Язык интерфейса зависит от региональных настроек операционной системы.
Кроме всего прочего, Ramus поддерживает возможность расширения функциональности с использованием сценариев на языке программирования JavaScript.
Ramus позволяет анализировать бизнес-процесс с трех ключевых точек зрения:
1. С точки зрения функциональности системы. В рамках методологии функционального моделирования IDEF0 бизнес-процесс представляется в виде набора функций, которые взаимодействуют между собой, а также показываются информационные, людские и производственные ресурсы, требуемые для каждой функции.
2. С точки зрения потоков информации в системе. Диаграммы DFD (Data Flow Diagram) дополняют функциональные IDEF0-модели, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. Также модели потоков данных могут использоваться как самостоятельное средство при проектировании информационных систем или описании бизнес-процесса, но в DFD-модели акцент ставиться на поток данных, его структуру, место и вид хранения данных в системе.
3. С точки зрения последовательности этапов выполняемых работ – методология событийного моделирования IDEF3. Этот метод привлекает внимание к очередности выполнения этапов работ или изменения состояний. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.
Моделирование действий c использованием метода IDEF0, является технологией анализа всей бизнес-системы, как набора взаимосвязанных действий и функций. Данная функциональная направленность является основной, так как функция в системе анализируется независимо от объектов, которые ее реализуют. Данная идея заключается в том, что функции в системе могут служить основой для формирования нового процесса и при этом не могут служить обособлено, как часть структурного анализа. Функциональная перспектива позволяет осуществить разделение задуманного от реализации.
Метод IDEF0 хорошо подходит в качестве инструмента анализа и моделирования функциональной системы организации.
К компонентам стандарта IDEF 0 следует отнести следующие:
функции (действия);
связи;
диаграммы.
Метод IDEF0 комбинирует графическую ограниченность (в модели присутствуют только два символа: прямоугольник и интерфейсная стрелка) со строгим и хорошо определенным процессом, которыми создается модель для улучшения качества законченности процесса.
Для того чтобы создать функциональную модель системы улучшения качества услуг, учитывая что гостиница оказывает своим клиентам широкий спектр услуг, был использован ППП ВРwin.. Цель работы – создать систему непрерывного усовершенствования и удовлетворения запросов потребителей гостиничных услуг.
Родительская диаграмма с названием «Обеспечивать непрерывное улучшение качества услуг» отображает систему в целом (рисунок 2). К данному функциональному блоку рисуются следующие виды стрелок:
1. Вход (Input) рисуется, как входящая в левую грань функционального блока. Вход показывает, что требуется для выполнения функции: Информация от клиентов; Внешние ресурсы; Деятельность конкурентов.
2. Выход (Output) – исходящая из правой грани блока. Выход – результат функции: Информация для потребителей; Качественные услуги; Непрерывно работающая система.
3. Механизм (Mechanism) входящая в нижнюю грань стрелка. Механизм с помощью чего или кого выполняется функция: Оргтехника; Генеральный директор; Сотрудники.
4. Управление (Control) рисуется входящей в верхнюю грань блока. Управление ограничивает выполнение функции: Устав и др. управляющие документы; Законодательные требования; Документация СМК; ГОСТы.
Рисунок 2. Контекстная диаграмма IDEF0. Функционирование пансионата.
Построение модели ИС начинается с описания функционирования предприятия (системы) в целом в виде контекстной диаграммы. Взаимодействие системы с окружающей средой описывается в терминах входа (на рис. 2. это «Клиенты» и «Оплата услуг»), выхода (основной результат процесса – «Оказанные услуги» и «Прибыль»), управления («Законы РФ» и «Устав гостиницы») и механизмов («Материальная база», «Помещение», «Персонал» – это ресурсы, необходимые для процесса функционирования гостиницы).
«Клиенты» – те, для кого гостиница работает. Они платят гостинице деньги в качестве платы за оказываемые услуги. Получение прибыли – цель коммерческой деятельности. Значит, чтобы добиться этой цели гостиница должна оказать услуги клиентам.
«Законы РФ» и «Устав пансионата» – это те правила, которыми управляется процесс функционирования пансионата, как предприятия со своими внутренними правилами, и также обязанного функционировать согласно законодательству конкретной страны.
В оказании услуг принимает участие «Персонал» пансионата, чтобы предоставить номерной фонд и получать прибыль, в деятельности пансионата должны участвовать «Номерной фонд» и «Материальная база» – обстановка здания, техника в номерах, инвентарь и т.д. После описания контекстной диаграммы проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. В результате такого разбиения, каждый фрагмент системы изображается на отдельной диаграмме декомпозиции (рис. 3).
Весь процесс «Функционирования пансионата» разбивается на:
1). «Предоставление номеров» иллюстрирует деятельность сдачи номеров с предварительной регистрацией.
2) «Обслуживание номеров» представляет собой процесс поддержания персоналом пансионата порядка в номерах;
3) «Обеспечение услуг телекоммуникации» – это совокупность оказываемых пансионатом услуг по предоставлению постояльцам телефона и интернета.
Рисунок 3 Диаграмма декомпозиции IDEF0. Функционирование пансионата
После дальнейшего разбиения диаграммы получаем 3 декомпозиции, каждая из которых описывает одну из работ, представленных на диаграмме верхнего уровня (на рис. 4).
Опишем диаграмму, представленную на рис. 4, с помощью отчёта, сгенерированного Bpwin:
Работа «Проверка счетов» иллюстрирует деятельность по формированию итогового и текущих счетов старшим администратором.
Рис. 4 Диаграмма декомпозиции IDEF0. Предоставление номеров.
Блок проверки взаиморасчетов и корректировки начислений будет автоматизироваться будет автоматизироваться в дипломном проекте. Т.к. отслеживание взаиморасчетов с клиентами очень важный аспект в любом виде деятельности, он требует к себе особого внимания. Для ускорения и упрощения работы по проверке взаиморасчетов и в некоторых случаях корректировке начислений будет произведена доработка, что позволит автоматизировать данный участок.
Слабые связи, не представленные на диаграмме высшего уровня:
Неоплаченные счета – итоговый счет или сводка текущих платежей за проживание в пансионате и пользование услугами, подсчитанный и проверенный бухгалтерией и направляемый администратору гостиницы для предъявления клиенту.
Полный счет гостя (Счет) –данные о платежах и счетах клиента в том виде, в каком они фиксировались у администратора и в отделе по регистрации телефонных переговоров и потреблении услуг интернета.
Резервирование номера – это процесс бронирования (квотирования) номера пансионата, которые займут уже известные клиенты, по запросу при оформлении размещения. До тех пор они не участвуют в деятельности по оформлению размещений.
Ключи от номеров – получаемые при размещении электронные ключи от номера.
Выбранные тарифы – категория номера, выбранная на стадии оформления въезда, влечет за собой суточный тариф проживания в пансионате.
Диаграмма, представленная на рисунке 5. напоминает контекстную диаграмму (рис. 2). Обе работы (на рис. 5) не зависят друг от друга и имеют на входах - «Клиентов» и «Плату за услуги», на выходах - «Оказанные услуги» и «Прибыль», на управлении – «Законы РФ» и «Устав пансионата», влияющие на всю деятельность пансионата, и на механизмах – «Материальную базу», «Помещение» и «Персонал» – ресурсы, необходимые для выполнения этих работ.
Эти виды деятельности пансионата мы не будем автоматизировать в ходе дипломного проектирования.
Рис. 5 Диаграмма декомпозиции IDEF0. Обслуживание номеров.
Оплата услуг связи осуществляется при оформлении выезда. В случаях, когда гость проживает длительный период, услуги связи оплачиваются ежемесячно. Выставление счетов за услуги связи производится из программы LanBilling. Все взаиморасчеты по услугам связи регламентно выгружаются и загружаются, что позволяет видеть всегда актуальную информацию по оплатам и начислениям по услугам связи.
Счёт – платежи за телефонные переговоры по междугородней связи, а также доплата за пользование телефоном гостиницы.
Переговоры – данные о времени, номере телефонного звонка.
На рис. 6. представлена диаграмма обеспечения телефонных переговоров.
Рис. 6. Диаграмма декомпозиции IDEF0. Обеспечение услуг связи.