Материал: Веб-система многопользовательского доступа к рабочей документации для сотрудников, работающих на дому

· DFD (Data Flow Diagrams) диаграммы потоков данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Как правило, диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0;

· IDEF3. Методология моделирования IDEF3 позволяет описать процессы, фокусируя внимание на течении этих процессов, позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций;

· ER (Entity-Relationship Diagrams) диаграммы "сущность-связь". Методология описания данных (IDEF1X).

На стадии моделирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

Применение универсальных графических языков моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов на этапе анализа.

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

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

IDEF3 предназначена для сбора данных, требующихся для проведения анализа системы с точки зрения рассогласования/согласования процессов во времени.

1.2.2. Язык UML

Язык UML (UnifiedModelingLanguage) представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем [3].

Этот язык одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. В рамках языка UML все представления о модели сложной системы фиксируются в виде специальных графических конструкций, получивших название диаграмм. В терминах языка UML определены следующие виды диаграмм [4]:

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

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

· Диаграмма состояний. Описывает процесс изменения состояний только одного класса, а точнее - одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне;

· Диаграмма деятельности. Представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к некоторому результату или действию. На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения;

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

· Диаграмма кооперации. Предназначена для спецификации структурных аспектов взаимодействия. Главная особенность диаграммы заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии;

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

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

В настоящее время объектный подход стал особенно популярен и характеризуется разработчиками как универсальное средство проектирования. Однако методология применения UML на этапах анализа и проектирования описана достаточно слабо, поэтому рано говорить о  UML как о действительно полноценной замене всем другим подходам.

1.2.3. Сравнение подходов к моделированию системы

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

Таблица 1– Сравнительный анализ нотаций IDEF, UML

Мною было решено использовать структурный подход к моделированию. Подход дает возможность проведения глубокого анализа бизнес – процессов, выявления узких мест: комплексное применение позволяет выявить все возможные рассогласования и неточности. Применение универсальных графических языков моделирования IDEF0, IDEF3обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов при моделировании предметной области в контексте«как должно быть».

1.3. Разработка SADT-моделей деятельности ООО «Бюро переводов Полиглот» как есть

Так как мы определили себе инструмент – структурный анализ и проектирование в виде диаграмм IDEF0 и IDEF3, то воспользуемся идеей построения моделей как есть для отражения снимка реальных событий. Начнем процесс с разработки контекстной диаграммы.

Рисунок 2 – Контекстная диаграмма модели

ДеятельностьООО «Бюро переводов Полиглот» строится вокруг оказания переводческих услуг. На контекстной диаграмме показаны входные, выходные потоки, механизмы и средства управления для процесса работы компании.

Рисунок 3 – Декомпозиция контекстной диаграммы

Процесс работы предприятия декомпозирован на четыре черных ящика.

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

На основе заказа клиента выполняется процесс выдачи задания переводчику. Здесь необходимо подобрать подходящего специалиста, выдать ему перечень документов и услуг, которые клиенту необходимо оказать.

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

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

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

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

Рисунок 4 – Модель процесса выдачи заданий

Выдача заданий – первый и основной проблемный процесс в рассматриваемом предприятии. Он заключается в следующем.

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

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

Затем следует вторая проблема в данном процессе – сотруднику лично предаются документы для перевода. Это архаичный процесс, который сопряжен с рисками утраты и нарушения тайны, если таковая требуется заявкой клиента. Опять таки повторюсь, что средств для удаленной выдачи, хоть их рынок сейчас и велик, не применяется. Тут вступают в силу и особенности предметной области, и требования клиента по конфиденциальности и т.д. Но главный фактор здесь – это то, что подавляющее большинство документов, а если быть точным – 93% [5], представлены в бумажном виде и требуют оцифровки. Это не обязательно должны быть OCR-технологии, сотрудники ООО «Бюро переводов Полиглот» не пользуются автоматическими переводчиками, так как это вопрос профессиональной этики и тексты с возможностью копирования и вставки им не нужны.

Рисунок 5 – Модель финансовых процессов

Процесс финансового учета в ООО «Бюро переводов Полиглот» тривиальный и совпадает с 99,9% подобных процессов в других фирмах. Строя его модель, я хотел показать что при выдаче денежных средств переводчику учитывается только его заработная плата. Этот момент в большей степени психологический. При переходе на работу на дому, человек готовится что в офис компании ему в лучшем случае придется явиться только для получения месячной заработной платы. Но как видно из рисунка 4, всем работающим сотрудникам надо появляться в офисе каждый раз при появлении задания для них. Соответственно, растут издержки и из своей заработной платы переводчик оплачивает себе частые поездки в офис, при этом остается работающим «на дому». Это и есть основная причина недовольства сотрудников своими выплатами.

Но перенести бремя оплаты транспортных расходов на ООО «Бюро переводов Полиглот» невозможно, так как число поездок заранее непредсказуемо и требуется четкая стандартизация удаленной работы.

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

1.4. Математическая модель оценки издержек переводчика на посещение офиса ООО «Бюро переводов Полиглот»

Рассмотрим типовые затраты переводчика для выполнения одной работы по переводу текста.Из рисунка 4 мы видим, что первым этапом является посещение офиса с целью получения задания и документов для последующего перевода. Временные затраты на нахождение в офисе обозначим как t₁. Временные затраты на дорогу до офиса обозначим как t₂, финансовые затраты обозначим как m₂.

Следующей операцией будет возврат переводчика домой, который оценивается по времени как t₂, финансово как m₂. Общие затраты на дорогу по времени обозначим как t₃= 2t₂, финансовые как m₃=2m₂. Перейдем к расчетам.

_- Переводчик перемещается на автомобиле. Пусть средний расход топливаA составляет 10л. / 100км;

_- Стоимость литра топлива P (Бензин АИ-95)– 39.50 рублей;

_- Среднее расстояниеS, которое необходимо проехать от дома до офиса, составляет 8 км.;

_- Средняя скоростьU автомобиля в городе – 24 км. / ч.;

_- За 1 задание автомобиль совершит 2 поездки;

_- Время нахождения в офисе t₁ составляет 30 минут.

Сведем исходные данные в таблицу 2.   

Таблица 2. – Исходные данные математической модели

Выведем формулы для расчета: Время, которое тратит переводчик на дорогу в одну сторону равно:

                                                        t₂ = (S / U)                                        (1)    

Где:

S – Среднее расстояние одной поездки

U – Средняя скорость автомобиля

Финансовые затраты на дорогу к офису и обратно определим по формуле:

                                               m₂ = (S * A/100* P)                                   (2)

Где:

S – Среднее расстояние одной поездки

A – Расход топлива

P - Стоимость литра бензина

         Рассчитаем значение временных затрат на дорогу. По формуле (1), t₂ = 20 мин. По формуле (2), рассчитаем денежные затраты на дорогу. m₁ = 31,6 руб. Итого общие временные затраты на дорогу по времени t₃ составят 40 минут, то есть почти 10% рабочего дня, общие финансовые затраты m₃ составят 63,2 рубля, то есть почти 17% от средней суммы заработка.