Формирование группы внедрения
С самого начало работы группы управления, мы стремились привлечь к участию в проектировании отдельных частей системы почасовых складских рабочих, что было необходимо для успеха проекта.
Группа внедрения была межфункциональной и состояла из представителей следующих отделов:
Инженерные коммуникации (менеджер проекта),
Отдел информационных систем,
Производственное планирование,
Распределение (управляющие и почасовые работники),
Полуфабрикатов (управляющие и почасовые работники),
Финансов.
Общее количество членов Группы внедрения составило 14 человек, и этот проект был признан приоритетным в том, что касается распоряжения временем членов этой группы. Насколько возможно, мы стремились забывать о наших должностях, когда проводили собрания группы или встречи с продавцом.
Получение информации напрямую от почасовых работников помогло выявить действительные, а не предполагаемые проблемы складского хранения. Мы исходили из того, что проект системы должен осуществляться через консенсус группы. Это означало, что каждый мог лично не соглашаться с решением, но поддерживать решение группы. (ПРИМЕЧАНИЕ: До формирования группы внедрения, все члены группы прошли обучение «Rubbermaid» по постоянному совершенствованию, где делался акцент на создании групп, работе в группе и умениях приходить к консенсусу.)
Синергетический эффект от работы Группы внедрения привел к появлению гораздо более разностороннего проекта системы, чем могли бы создать члены группы по отдельности. Другим важнейшим элементом работы группы была вовлеченность всех членов группы в этот проект. Этот проект системы управления складом был, возможно, наиболее сложным для любого из нас. Члены группы помогали при внедрении системы на двух объектах в Винфилде, особенно на самом складе, где система с радиотерминалами, работающими в реальном времени, стала радикальным переходом от бумажной системы.
|
|
|
Никогда не недооценивайте требования к ресурсам
Как менеджер проекта, я выучил один из самых важных уроков при проектировании и внедрении этой системы: НИКОГДА НЕ НЕДООЦЕНИВАЙТЕ ТРЕБОВАНИЯ К РЕСУРСАМ. Во время календарного 1993 года, когда происходило проектирование нашей системы, разработка ПО, установка радиотерминалов, первоначальное обучение пользователей и проверка системы, наша Группа внедрения потратила свыше 11000 человеко-часов на этот проект. Это эквивалентно почти шести человеко-годам, или шести людям, работающим полный рабочий день в течение года и занимающихся только проектом системы управления складом. Если вы сами не занимались подобным проектом, то исключительно трудно оценить, сколько времени потребуется для осуществления такого проекта.
|
|
|
Одним из наших руководящих принципов было то, что компания «Rubbermaid» никогда не должна быть «узким местом» или задерживать проект. Мы хотели оказывать давление на системного интегратора, требуя соблюдения всех дат промежуточных этапов, чтобы ему не приходилось ждать нас (заказчика) при выполнении задачи.
Нужно ли говорить, что чтобы получать необходимые внутренние ресурсы для такого проекта, высшее руководство должно обеспечивать поддержку и предоставление этих ресурсов. Без такой поддержки, заказчик становится «узким местом», и драгоценные ресурсы продавца (люди) отправляются на другой проект. Системный интегратор не может себе финансово позволить бездельничать в ожидании заказчика.
Похожей аналогией будет наш производственный объект, который мы используем для обучения работающих на производстве людей. Когда наш станок для литья пластмасс под давлением или пескодувная формовочная машина не изготавливают качественные детали из-за простоя или брака, то машинное время и труд оператора потеряны навсегда.
Возможности для полного использования не только ресурсов продавца, но поддержания работы над проектом внутри компании ограничены. Чем больше проект откладывается, тем труднее собрать необходимые людские ресурсы от обеих сторон проекта.
|
|
|
Менеджер проекта
Одно из условий обеспечения прогресса проекта, а также наличия внутренних ресурсов – это роль, которую играет менеджер проекта. Я обнаружил, что моя роль как менеджера проекта постоянно сводилась к выполнению следующих задач:
1. Организационные умения
Мне приходилось непрерывно отслеживать ключевые элементы каждой стадии проекта, чтобы обеспечить соблюдение графика членами группы, функциональными отделами и продавцом. Сюда входили не только проектирование функционального ПО от приемки до отгрузки, но также:
348.Спецификации и аппаратные средства для системы радиотерминалов,
349.Спецификации аппаратных средств RS/6000,
350.Разработка ПО продавцом,
351.Составление карты склада,Создание данных для параметров мест и единиц хранения,
111.Тестирование системы,
112.Обучение пользователей,
113.Экспериментальный запуск системы,
114.Окончательный запуск системы,
115.Планирование на случай ЧП.
Каждый из этих элементов был сам по себе проектом, который требовал формального планирования, документирования и распределения ответственности. Можно очень легко утратить нити управления проектом, если пренебречь любым элементом в графике разработки проекта.
|
|
|
Способность работать над множеством приоритетов одновременно была для меня каждодневным требованием, потому что большинство элементов накладывались друг на друга во времени. Я не имел возможности сфокусироваться на одном элементе от начала до конца и только затем переходить к следующему. Такие сложные и продолжительные проекты очень динамичны, с постоянными изменениями и дополнениями.
2. Никто в одиночку не сможет предоставить необходимые знания и время для проектирования и внедрения системы управления складом. Единственный способ здесь в объединении талантов и возможностей разных людей организации.
Распределение ответственности за задачи означало, что много времени у меня уходило на помощь в сотрудничестве и согласованных действиях группы при продвижении вперед. Задача объединить моих товарищей по группе из разных функциональных отделов для достижения согласия по важным вопросам и эффективной совместной работы как группы выходила далеко за рамки моей формальной роли главного инженера.
Как главный инженер, я имел право определять приоритеты и задачи для работающих в компании инженеров, и был уверен, что эта работа будет выполнена. Это было частью моих должностных инструкций и отражалось в организационной схеме отдела.
Однако, как менеджер проекта и руководитель группы по системе управления складом, я не имел власти над остальными членами группы, поэтому мои лидерские качества и управленческие навыки были даже более важны для успешного решения задач проекта.
3. Стало очевидно во время работы над проектом, что одна из моих наиболее важных ролей как менеджера проекта (хотя и неофициальная) была в том, чтобы быть "борцом" за проект системы управления складом. Это означало, что мне приходилось постоянно сражаться с противником на пути осуществления проекта, будь то негативное отношение, проблемы продавца, споры или конфликты в группе, распределение денег или информирование руководства о продвижении в осуществлении проекта.
Я должен был демонстрировать несгибаемую веру в наш проект и поддерживать усилия группы по поэтапному созданию нашей системы. Человеческий фактор при технологических изменениях очень важен, но слишком часто недооценивается. Моя неофициальная роль "борца" означала преодоление человеческих страхов и сопротивления значительным изменениям среди управляющих, членов группы и пользователей системы.
Один из самых больших рисков был в том, что Группа внедрения могла утратить необходимый для завершения проекта темп работ. Это бы значительно затруднило одобрение системы пользователем и могло привести к напрасной трате времени и денег при разработке системы.
Дата добавления: 2019-03-09; просмотров: 543; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!