1. Одноуровневая реализация без использования Spider Project исполнителями
В случае, когда в небольшой компании количество производимых одновременно работ невелико, а все работы с моделями проектов производит один планировщик, исполнители могут аккумулировать фактические данные по исполнению объемов работ любым удобным для них способом без использования Spider Project. Объемы этих данных невелики и требовать от линейных сотрудников освоения дополнительной компьютерной программы ради небольших периодических действий непродуктивно.
В определенный регламентом момент времени планировщик формирует в программе Spider Project таблицу учета, т.е. плановое задание исполнителям на следующий отчетный период (день, неделя, квартал и т.д.), и рассылает фрагменты таблицы в виде текстовых электронных писем, таблиц Excel, передает в виде распечаток из Spider Project, либо доводит лично устно посредством голосовой связи или письменно при помощи интернет-коммуникаций.
В определенное регламентом время ответственный сотрудник обязан сообщить планировщику информацию о выполненных объемах, затраченных суммах, расходах материалов, времени и количестве работавших ресурсов, отмененных или сверхплановых операциях и прочих изменениях, произошедших в его зоне ответственности за учетный период. Передача информации производится любым удобным способом от устного до электронного. Состав же передаваемых данных определяется утвержденным внутренним регламентом организации.
Если исполнители передают планировщику специальным образом отформатированные таблицы Excel, то планировщик может переносить учетную информацию в модель посредством перевода данных таблиц в документы учета в формате Spider Project или непосредственным копированием групп ячеек с данными в таблицу учета Spider Project из таблицы Excel.
В данном варианте взаимодействия полученные данные планировщик модели самостоятельно вносит в таблицу учета проекта и производит проверку корректности поступившей информации. После расчета модели, анализа, произведенного аналитиком, и принятия руководством компании (руководителем проекта) управленческих решений на основе полученных данных, планировщик формирует исполнителям задание на следующий учетный период. Далее цикл повторяется.
2. Одноуровневая реализация с использованием Spider Project исполнителями (рассылка-сборка таблиц учета в виде документов)
В данном типе групповой работы действия планировщика во время формирования задания исполнителям и сбора учетной информации отличаются от предыдущего варианта. Работа же исполнителей подразумевает использование программы Spider Project.
Для организации групповой работы с исполнителями администратор модели проекта должен создать в модели (таблица «Пользователи») записи этих пользователей, после чего назначить их ответственными на соответствующие фазы модели проекта. Это адресаты-получатели планового задания (учетных документов). В случае, если исходная технологическая модель проекта по своей структуре не может быть разделена на фазы в соответствии с исполнителями, то планировщику необходимо создать дополнительную структуру модели «По ответственным», в которой в соответствующих фазах будут аккумулированы задачи только конкретного исполнителя, и производить рассылку-сборку в этой структуре.
У пользователей в модели проекта планировщик настраивает способ передачи информации к ним и от них. Это может быть электронная почта, локальная сеть, виртуальная сеть или FTP сервер организации. Современные облачные технологии позволяют компаниям с распределенными по разным городам точками присутствия организовывать хранилища для рассылки-сборки при помощи DropBox, OneDrive, GoogleDisk и подобных сервисов. Для получения и отправки данных пользователем в его профиле должны быть настроены соответствующие папки в локальной сети, виртуальной сети, облачном хранилище или на FTP-сервере. Одна – для получения данных от планировщика, другая – для отправки готовых данных планировщику.
В случае рассылки учетных документов электронной почтой, планировщик, к сожалению, лишается возможности производить автоматическую сборку документов таким же способом, поскольку формат электронных писем при массовой отправке поддается формализации, а обратная почта с фактическими данными может иметь непредсказуемый формат. Исполнитель может вложить данные в письмо в виде документа учета в формате Spider Project, но может также и произвести сжатие файлов перед вложением одним из архиваторов.
В случае работы с электронной почтой планировщику необходимо вручную извлечь присланные данные из электронных писем и переместить в соответствующую папку для последующей сборки.
Конечно же, существует возможность полностью автоматизировать сборку учетных данных и в случае использования электронной почты. Эта задача решается не средствами Spider Project, а соответствующим жестким регламентированием формата писем и настройкой автоматического сценария (правила) обработки входящих сообщений почтового сервера компании. Например: письма с данными для сборки должны приходить строго на определенный электронный адрес incoming@mycompany.com, поле Subject (Тема) письма должна содержать фамилию ответственного (номер участка, код и т.п.) по которому сработает сценарий (правило), а файлы документов Spider Project должны быть вложены в письма однотипно (запрещено применение архиваторов). После этого почтовый сервер автоматически извлечет файлы из писем и поместит их в соответствующие папки.
В момент сборки учетных данных в модель планировщик увидит отчет программы о неудачной сборке фрагментов данных от конкретного ответственного, если что-то пошло не так (сбой сети, потеря письма, ошибка обработки почты) или данные предоставлены не были, и сможет предпринять соответствующие оперативные меры.
Порядок действий
Планировщик формирует в модели таблицу учета, соответствующую периоду учета. После этого производит из программы рассылку учета в виде документов. Файлы документов автоматически размещаются в папках исполнителей или отправляются исполнителям по электронной почте.
Исполнитель открывает таблицу учета непосредственно из своей входящей папки в локальной сети, виртуальной сети, облачного хранилища или с FTP-сервера. После внесения учетных данных он сохраняет документ в исходящую папку. Или отправляет файл по электронной почте. Spider Project позволяет получать и отправлять документы используя для этого одну и ту же папку. Программа производит отслеживание актуальных версий документов. Путаницы не будет.
В соответствии с регламентом планировщик запускает сборку учетных данных и Spider Project автоматически собирает файлы документов учета из исходящих папок исполнителей. После успешной сборки модель готова к расчетам с учетом новой фактической информации.
В этот момент изменилось Текущее время проекта. Текущее время проекта – это не текущая дата на календаре. Текущее время проекта – это последний момент времени, за который были внесены учетные данные. Если мы приняли решение собирать учет помесячно 1-го числа, то модель с текущим временем 1 мая будет оставаться таковой до 1 июня, пока не произойдет сборка фактических данных за май месяц и с учетом этих данных модель не будет пересчитана. После этого текущее время проекта станет 1-м июня.
В данном случае, в течение всего месяца аналитик может производить с моделью разнообразные эксперименты и проигрывать различные варианты дальнейшего движения проекта для проведения анализа.
Поскольку исполнители работают только с учетными документами формата Spider Project, они могут использовать бесплатную демо-версию Spider Project. Демо-версия имеет ограничения только на размер открываемых или создаваемых моделей (40 операций), но табличные документы открывает любой размерности.
Относительно внеплановых и отмененных работ
Исполнитель, внося учетные данные, может исключить из списка работ те, которые не исполнялись за отчетный период. Также он может произвести добавление внеплановых работ, но подобные действия требуют очень высокого уровня владения программой Spider Project, а также наличия у исполнителя дополнительной полной информации о всех ресурсах, материалах и прочих сущностях модели проекта, которая у него обычно отсутствует. Поэтому настоятельно рекомендуется подобные изменения фиксировать и отдельно сообщать планировщику в момент сборки учетных данных, чтобы он произвел соответствующие изменения непосредственно в модели.
Наиболее простое и позволяющее исключить ошибки решение данной задачи – сообщить планировщику об изменении перечня работ перед внесением учетных данных и попросить его сформировать таблицу учета для конкретного исполнителя еще раз с учетом произведенных изменений.
Документ, отсылаемый исполнителю, поддается очень тонкой настройке в свойствах данного исполнителя. Администратор модели может настроить полную конфигурацию отправляемого документа в соответствии с требованиями по внесению учета к данному исполнителю, сферой его компетенций, сохранения конфиденциальности определенных данных и так далее. Исполнитель получит учетный документ только с теми записями и полями, которые ему необходимо видеть и обрабатывать.
3. Двухуровневая реализация с использованием Spider Project исполнителями (рассылка-сборка фаз)
В данном варианте групповой работы главный планировщик/аналитик проекта производит рассылку не учетных документов, а полноценных фрагментов модели (фаз) ответственным или планировщикам/аналитикам более низкого уровня. Получаемая планировщиком/аналитиком (ответственным) информация представляет собой фазу модели проекта, за исполнение работ которой он является ответственным. Планировщик/аналитик (ответственный) самостоятельно, как в варианте 1, производит формирование таблицы учета и последующее ее заполнение полученными фактическими данными, либо рассылает таблицы учета в виде документов Spider Project непосредственным исполнителям работ для заполнения, как в варианте 2.
Если планировщику/аналитику проекта необходимо предоставить планировщикам/аналитикам (ответственным) на фазах дополнительную информацию по производству работ на соседних влияющих фазах проекта, то он может произвести настройку в свойствах планировщиков/аналитиков фаз так, чтобы при рассылке они получали проект полностью или частично. В настройках прав доступа есть возможность ограничить видимость фаз, операций и других сущностей модели, которые при рассылке не должны быть доступны данным сотрудникам.
Планировщики/аналитики нижнего уровня (ответственные) могут производить сбор учетных данных с более коротким временным периодом, чем главный планировщик/аналитик. Например: по фазам сбор учетной информации производится два раза в неделю, а сбор информации в общую модель производится раз в неделю, квартал, в месяц.
Периоды сбора учетных данных (периоды учета) на всех уровнях тщательно прорабатываются компанией из соображений потребности в фактической информации руководства для принятия своевременных решений, потребности в оперативной информации всех заинтересованных служб, и для максимальной управляемости производимых работ.
При очень коротком периоде учета возрастает нагрузка на предоставляющих фактические данные исполнителей и планировщика/аналитика, которому необходимо обеспечивать анализ поведения модели с учетом поступивших данных и подготовку отчетной информации руководству проекта или компании, коим тоже необходимо время для принятия решений. Поступившая фактическая информация и соответствующая аналитика может просто не успевать доводиться проектным офисом руководству. В данном случае управляющие воздействия на план производства работ будут несвоевременны и неадекватны происходящему, а поток информации излишним.
При очень длительном периоде учета возможна обратная картина – объемы производимых работ и происходящие изменения уже требуют управленческого воздействия, но фактическая и аналитическая информация поступит руководству не сразу, а когда поступит, то данные воздействия уже станут неактуальны, поскольку время упущено и фактическая картина изменилась.
4. Многоуровневая реализация с использованием Spider Project. Объемные проекты, портфели.
По аналогии с описанным вариантом 3 производится групповая работа с объемными проектами, имеющими многоуровневую иерархическую структуру, а также с портфелями проектов.
Алгоритм программы проверяет уровень рассылки на каждом уровне. Поэтому при рассылке планировщиком/аналитиком 1 уровня фрагментов или проектов ответственным 2 уровня игнорируются следующие уровни иерархии ответственности. Каждая ступень осуществляет рассылку-сборку только в пределах одного уровня вниз.
В отличие от рассылки-сборки отдельных фаз проекта при рассылке-сборке проектов, входящих в портфель, планировщики/аналитики проектов получают полноценную модель собственного проекта с возможностью производить расчеты как с учетом влияния портфеля, так и без учета этого влияния.