42
Были запланированы мероприятия по изменению статусов всех ИНС,
которые в действительности не являлись активными и работы, по которым не
велись. С точки зрения процесса были организованы работы по формированию
лимитов ИНС, при превышении которых, автоматически формировалось
предупреждение и направлялось в отдел управленческого учета и финансового
контроля для принятия решения о рациональности работы с данными
Заказчиками.
Описанные мероприятия легли в основу создание системы, которая
отражала бы полную картину по трудозатратам и способствовала принятию
взвешенных управленческих решений.
.
43
РАЗДЕЛ 3. ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА СИСТЕМЫ УЧЕТА
ТРУДОЗАТРАТ
3.1. Разработка концепции системы учета трудозатрат
Для повышения качества управления ресурсами и оптимизации расходов
в этой области в Компании необходимо создание прозрачной системы учета
трудозатрат, хранящей в себе достоверные (подтвержденные руководителем) и
актуальные данные. Руководители любого уровня должны иметь под рукой
инструмент (программное обеспечение и методологию), с помощью которого
они смогут своевременно реагировать на изменения в проекте в части
использования ресурсов – проводить анализ загрузки и эффективности
использования ресурсов Компании.
Основными проблемами Компании в части учета трудозатрат на текущий
момент являются:
отсутствие полной информации о загрузке сотрудников ТП;
отсутствие инструмента для проведения анализа и получения оценок
состояния проекта;
Как следствие:
o невозможность разрабатывать и принимать обоснованные стратегические
управленческие решения;
o нерациональная загрузка технического персонала;
o высокие постоянные расходы компании из-за отсутствия возможностей
контроля издержек проекта и подразделений.
Целью проекта является обеспечение в Компании полного учета рабочего
времени ТП. Достичь цели предполагается с помощью оптимизации
существующих бизнес-процессов Компании (в рамках проекта по оптимизации
БП) и автоматизации наиболее трудоемких процедур данных процессов
(разработка и внедрение системы учета трудозатрат – модуля «TimeSheet» на
платформе DAX).
Ключевыми результатами внедрения данного модуля являются:
44
Единые подходы к учету рабочего времени и унификация сбора
фактических данных;
Исключение двойного ввода данных о трудозатратах;
Консолидация всей информации о трудозатратах технических
подразделений в единой системе для своевременного расчета ресурсных и
финансовых показателей эффективности проектов и подразделений;
Обеспечение высшего руководства необходимыми аналитическими
данными с целью предоставление возможности принятия взвешенных
управленческих решений.
На основании требований к разработке план-графиков проектов для
каждого проекта, по которому заключен договор создается календарно-сетевая
модель в MS Project Server. Данная модель содержит сведения о содержании
проекта, работах и их взаимосвязях в соответствии с прописанными в договоре
условиями. Поэтому основными требованиями к создаваемой системе
являются:
По всем задачам плана проекта в системе учета трудозатрат должны
отражаться актуальные данные о запланированных часах (в связке: проект -
название проекта, ID задачи плана-график, название задачи план-графика,
назначенный ресурс).
По всем фактическим трудозатратам задачи сотрудника
сформированные в СУЗ должны быть однозначно сопоставлены с задачами
план-графика MS Project.
В части учета трудозатрат важным моментом является недопущение
двойного ввода данных в связи со спецификой проектов и большим
количеством специализированных информационных систем, в которых
вынуждены работать сотрудники. Также этот момент играет существенную
роль в управлении ресурсами для линейных руководителей. Поэтому
разрабатывалось решение, которое могло автоматически фиксировать рабочее
45
время, потраченное сотрудниками и подтвержденное их руководителями в
СУЗ.
Предлагаемое решение – приложение на базе технологий Microsoft на
платформе Dynamics Axapta 2004. Было выбрано это ПО в качестве «базы», так
как весь персонал категории АУП (руководители программ, проектов)
использовали данный инструмент для принятия управленческих решений.
Реинжиниринг процесса проводился одновременно с разработкой
системы и оценкой ее функциональных возможностей, чтобы максимально
оптимизировать процесс, автоматизировать самые сложные и трудоемкие
процессы по учету.
Для работы Системы были предложены следующие сервера и ПО
(описание в Таблица 4):
Таблица 4
Требования к инфраструктуре системы учета трудозатрат
Роль
сервера
Количество
серверов
данной
роли
Центральный
процессор
Оперативная
память
Жестки
й диск
Программное
обеспечение
Сервер
приложений
2
64-разрядный,
4 ядра,
минимум 2.5
GHz
16 GB
100 GB
MS Windows Server
2012 R2 Standard
Сервер баз
данных
1
64-разрядный,
8 ядер,
минимум 2.5
GHz
16 GB
100 GB
MS Windows Server
2012 R2 Standard,
MS SQL Server 2014
Standard
В целях снижения нагрузки на основного сервера компании и
недопущения снижения производительности текущих корпоративных
информационных систем принято решение о создании системы хранения
данных о трудозатратах и установке дополнительного жесткого диска для
Сервера баз данных. Общая схема решения приведена на Рисунок 18.
46
Система
Сервер приложений 1
Сервер баз данных
Сервер приложений 2
DAX HR-система
Jira Remedy
1 2
3
3
Пользователь
4
Рисунок 18 – Принципиальная схема взаимодействия
На основании проведенного анализа и выявленных слабых точках
процесса была определена следующая последовательность работы Системы:
1. Система использует информацию о сотрудниках, проектах, этапах,
задачах, их плановой длительности из DAX. Данные справочники
импортируются во все остальные системы и регулярно обновляются, таким
образом единой информационной витриной выступает DAX. Все пользуются
едиными справочниками и кросс-системными связками элементов.
2. Из HR-системы поступает информациях об отпусках и
сверхурочных часах работы. Сотрудники не тратят времени на внесение
информации об отпусках или больничных, которые они уже оформляли в
других системах и которые были официально проведены по 1С: ЗУП.
3. Из систем Jira, Remedy поступает информация о фактических
затратах на задачи, которые сотрудники указывали в процессе их деятельности
под контролем их линейного руководителя, главного инженера проекта, либо
руководителя проекта.
4. Пользователь, в зависимости от роли, может:
a. Скорректировать фактические затраты для конкретных задач;
b. Отправить фактические затраты на согласование;
c. Согласовать либо отклонить полученные на согласования данные;
d. Создать и экспортировать отчеты «план-факт».
47
Интеграция с каждой из систем (DAX, HR, Jira, Remedy) происходит с
помощью стандартного API. Если использование стандартного API
недостаточно (либо невозможно), возможно расширение функций систем или
изменение IT-ландшафта (коммутация сетей, настройка сетевых экранов).
Основная задача по исключению двойного вода данных должна быть
реализована техническими средствами в целях экономии времени,
использования единых источников данных и снижения градуса напряженности
в компании в связи с увеличением требований к заполнению дополнительных
отчетов.
Первоначальное наполнение существующими данными происходит с
помощью специально разработанной утилиты.
Интеграционный модуль (шина): функционал обеспечивающий передачу
данных (план-факт) между перечисленными выше системами. В общем виде
ИТ-ландшафт системы учета трудозатрат должен выглядеть следующим
образом:
DAX.
Перечень проектов
и задач и
назначение
ресурсов (план)
1
Системы
управления
задачами (Jira, MS
Project, Remedy).
Детализация до
подзадач
СУТ
Корректировка и
согласование ТЗ
3
2
Передача данных о
сотрудниках из кадровых
систем (действительный
фонд рабочего времени,
роль и т.д.)
Рисунок 19 – Схема взаимодействия информационных систем
Разрабатывалась интеграционная шина между DAX и кадровой учетной
системой. DAX является центральной витриной данных для всех
информационных систем, в том числе в предоставлении информации по ролями
и ставкам сотрудников. Актуальность этих данных обеспечивается
периодическим обновлением справочников ресурсов и ставок из кадровой
системы учета.
48
Важное значение уделяется внутреннему взаимодействию DAX и MS
Project, как основным системам управления проектами, ресурсами и
предприятием в целом. Должна быть обеспечена передача плановых
трудозатрат, наименований проектов и работ, которыми управляют
руководители проектов и программ. В целях анализа доступности, возможности
выделения ресурсов на проект, а также непротиворечивости данных при
формировании управленческой отчетности из DAX в СУЗ должны передаваться
актуальный данные on-line о проектах их статусах и остальных показателях.
Другая интеграционная шина представляет собой набор интеграционных
инструментов между ИСУП и СУЗ для передачи задач и ресурсного плана из
ИСУП в СУЗ для последующей детализации. ИЗ MS Project передаются только
выбранные задачи, после чего в СУЗ автоматически генерируется набор задач
(по принципу одна задача – один исполнитель), которые привязываются к
задаче основного ПГ для управления проектом (а не технологическими
процессами проекта).
Реализуется функция автоматической передачи фактических данных о
трудозатратах из СУЗ в TimeSheet. Передача утвержденных трудозатрат из СУЗ
на задачи в MS Project в соответствии с категорией рабочего времени (расчет
стоимости на основании действующих стандартных ставок, сверхурочных и
т.д.).
Рисунок 20 – Целевая Функциональная модель системы учета трудозатрат
Была проведена оценка компетенций компании и сформирована рабочая
группа по разработке системы в соответствии с требованиями. На основании
49
опыта внедрения систем такого рода в компании, были выделены следующие
этапы и задачи, которые представлены в Таблица 5.
Таблица 5
Оценка трудоемкости этапов проекта
Эта
п
Задача
Трудоемкость,
рабочих дней
Этап 1: Обследование и документирование
21
1.1
Разработка технического задания
10
1.2
Разработка ПМИ
5
1.3
Управление проектом
6
Этап 2: Функциональный дизайн и разработка
178
2.1
Разработка механизма получения данных об орг. Структуре
(DAX)
5
2.2
Разработка механизма получения данных о плане (DAX)
5
2.3
Разработка механизма получения данных о плане (HR:
больничные, отпуска)
5
2.4
Разработка механизма получения данных о факте (Jira)
5
2.5
Разработка механизма получения данных о факте (Remedy)
5
2.6
Разработка механизма получения данных о факте (Excel)
20
2.7
Разработка интерфейса редактирования факта – форма
сотрудника
20
2.8
Разработка интерфейса согласования факта – форма
владельца задачи
20
2.9
Разработка интерфейса согласования факта – форма
владельца ресурса
20
2.10
Разработка утилиты миграции
10
2.11
Тестирование
14
2.12
Управление проектом
44
Этап 3: Ввод в эксплуатацию
13
3.1
Установка решения в среде Заказчика
2
3.2
Проведение приемо-сдаточных испытаний
5
3.3
Обучение сотрудников заказчика
2
3.4
Управление проектом внедрения СУТ
4
Ито
го
212
Состав рабочей группы по этапам представлен в Таблица 6.
Таблица 6
Состав рабочей группы по этапам
Роль
ФИО
Трудоемкость, рабочих дней
Этап 1: Обследование и документирование
21
Аналитик
А. Чулкова
15
50
Роль
ФИО
Трудоемкость, рабочих дней
Руководитель рабочей группы
А.Сметанин
3
Архитектор
К. Лемесев
3
Этап 2: Функциональный дизайн и разработка
178
Программист 1
А.Мосин
60
Программист 2
С. Жулидов
60
Тестировщик
А. Чулкова
14
Руководитель рабочей группы
А.Сметанин
22
Архитектор
К. Лемесев
22
Этап 3: Ввод в эксплуатацию
13
Программист 1
А.Мосин
2
Аналитик
А. Чулкова
7
Руководитель рабочей группы
Д. Зоткин
2
Архитектор
К. Лемесев
2
Итого
212
Перечисленные этапы исполняются последовательно. Календарная
длительность этапов представлена в Таблица 7.
Таблица 7
Календарная длительность этапов
Этап
Длительность,
рабочих дней
Этап 1: Обследование и документирование
10
Этап 2: Функциональный дизайн и разработка
70
Этап 3: Ввод в эксплуатацию
9
Итого:
89
При разработке системы были учтены следующие допущения и
ограничения:
1. В целях обеспечения всех сотрудников единым набором
справочников, создаваемая информационная Система должна быть
интегрирована со следующими информационными системами Заказчика:
MS DAX;
Atlassian Jira;
BMC Remedy;
ИС департамента HR (1С: ЗУП).
2. Инструменты для создания планов графиком заложены в систему
MS DAX по средствам импорта из MS Project Server 2007.
51
3. Любые словари и справочники будут предоставлены со стороны
третьих систем. В рамках проекта редактирование справочников не
предусмотрено.
4. Сопоставление между плановыми этапами-задачами (задачами из
плана графика проекта) и фактическими задачами («тасками» в СУЗ) будет
предоставлены со стороны третьих систем.
5. Связи «проект-задача» будут предоставлены со стороны третьих
систем.
6. Все пользователи Системы имеют активные учетные записи в
домене NVG.
7. Количество пользователей Системы – до 3170 человек.
8. Система рассчитана на последние версии следующих браузеров ОС
Windows:
a. MS Internet Explorer,версии 9, 10, 11
b. Mozilla Firefox, версии 32, 33, 34
c. Google Chrome, версии 37, 38, 39
d. Apple Safari, версии 6, 7, 8
9. В рамках проекта не требуется создания и согласования дизайн-
макетов страниц/экранов Системы. Достаточно схематичного описания
возможностей графического интерфейса пользователя.
10. В Системе будет реализовано не более трех основных экранов для
работы пользователей.
11. Разграничение доступа основано на статической ролевой модели.
Ролевая модель содержит не более трех ролей.
12. Инструменты для администратора система ограничены
инструментами предоставляемыми платформами MS Windows и MS SQL
Server.
13. Список сценариев, которые будет автоматизировать Система,
следующий: