Назад: 4.3.Коммуникация и конфликты
Дальше: 4.3.2.Командообразование
4.3.1.Удаленное взаимодействие
Распределенные команды (виртуальные команды) в XXI веке стали нормой. Процесс глобализации проектов способствовал появлению потребности в виртуальных командах, члены которых при работе над одним и тем же проектом находятся в разных местах (городах и даже странах). Работа таких команд стала возможной благодаря средствам коммуникации через Интернет:
- электронная почта;
- аудио- и видеоконференции;
- мессенджеры;
- общий доступ к документам;
- онлайн-совещания и вебинары, основанные на веб-технологиях интерактивного показа удаленного рабочего стола, голосового и текстового общения;
- виртуальные сети и удаленный доступ;
- таск-трекеры.
Управление виртуальными командами открывает уникальные благоприятные возможности – например, возможность использовать особые знания и опыт в работе команды проекта даже в тех случаях, когда эксперт физически далеко от остальных членов команды. Можно привлекать работающих на дому сотрудников, а также людей с ограниченными по мобильности возможностями.
Современные технологии позволяют проводить внедрение ERP-системы для ряда предприятий в большей части дистанционно, это позволяет заказчику привлекать исполнителя из любого города, минимизируя накладные расходы на командировки и место в своем офисе для всей команды. Со стороны исполнителя – экономия на аренде большого офиса, возможность привлечения специалистов из других городов (виртуальный офис).
Проблемы управления виртуальными командами связаны главным образом с коммуникациями, включая возможное чувство изолированности, проблемы в обмене знаниями и опытом между членами команды, а также трудности в отслеживании хода работ и эффективном расходовании времени (за спиной у сотрудника уже не постоишь, но у них и мотивация не по таймеру работать, а на результат).
Нужно также учитывать разницу во времени и часовых поясах. Если заказчик и исполнитель в разных часовых поясах, то исполнителю на время проекта логично перестроиться и минимизировать сдвиг времени с заказчиком. Особенно это актуально для поддержки на фазах опытной и промышленной эксплуатации системы. Если же команда самого исполнителя находится в разных часовых поясах, то это может стать преимуществом, если часть специалистов находятся в часовом поясе заказчика. Если же у заказчика филиальная структура в разных часовых поясах, то для его оперативной поддержки исполнителю тоже логично иметь специалистов в этих же часовых поясах, либо временные сдвиги и время реакции нужно явно зафиксировать в договоре и учитывать при планировании взаимодействий.
При всем многообразии доступного инструментария для удаленного взаимодействия нужно ограничить используемый инструментарий, чтобы не было ситуаций: «Я тебе скинул файл, ты смотрел? Куда скинул? В WhatsApp, Skype, на e-mail (на какой адрес?), в сетевую папку, гуглдок, яндексдок, в общий форум, в чат…»
Чем больше каналов связи, тем больше путаницы будет в них, т. к. кто-то любит одно, а другого у него нет, кто-то совсем другое и они не пересекутся и общаться, например, через единый мессенджер не смогут.
Нужно договориться внутри команды и со специалистами заказчика (у них могут быть свои ограничения на запуск софта из-за требований безопасности) – и выбрать единый набор инструментов, где на уровне регламентов зафиксировано, что, например, все рабочие документы передаются только по электронной почте с определенных адресов.
Для работы с проектами внедрения и поддержки 1C:ERP хорошо подходит специальный инструмент «1С-Коннект» () – это корпоративный мессенджер, центр уведомлений и ServiceDesk с множеством различных специальных опций, отсутствующих в обычных мессенджерах для простых пользователей.
Серьезным вызовом для «удаленки» стал 2020 год и карантин во многих странах из-за COVID-19. Даже стойкие противники такого взаимодействия были вынуждены настраивать режим удаленной работы для сотрудников и внешних партнеров. Это стало вопросом выживания бизнеса и дало практический опыт всем. Поэтому в настоящее время к «удаленке» уже нет такого пренебрежения, как было до кризиса.
Возможности удаленного взаимодействия нужно выяснять заранее и закладывать в сроки и бюджет как оптимизацию расходов или, наоборот, удорожание проекта и увеличение его сроков.
Но даже при хорошо налаженной удаленной работе стоит периодически встречаться очно, особенно в начале проекта, на этапе выстраивания отношений, и на этапе опытной эксплуатации, когда коммуникации при первичной поддержке наиболее востребованы. Поэтому проект нужно спланировать, исходя из периодов очного присутствия специалистов исполнителя на территории заказчика, на фоне основной удаленной работы.

- 1. Обложка
- 2. Титульный лист
- 3. Выходные данные
- 4. Введение
- 5. Принятые термины и сокращения
- 6. Глава 1. Что такое ERP-система и зачем она компании
- 7. 1.2.Отличие ERP-системы от учетной бухгалтерской системы
- 8. 1.3.Зачем ERP-система компании
- 9. 1.4.Затраты на владение системой (стоимость эксплуатации)
- 10. 1.4.1.Облачные сервисы как путь снижения затрат
- 11. Глава 2. Как выбрать ERP-систему
- 12. 2.2.Тендер и участие в нем
- 13. 2.2.2.Со стороны исполнителя
- 14. 2.3.Fit-gap анализ разных систем
- 15. 2.4.ИТ-ландшафт текущий и перспективный
- 16. 2.5.Нагрузочные тесты и выбор «железа»
- 17. 2.6.Окупаемость и обоснование затрат на автоматизацию
- 18. Глава 3. Как внедрять ERP-систему
- 19. 3.1.1.Agile-методологии
- 20. 3.1.2.Серия стандартов ISO
- 21. 3.1.3.ГОСТ 34
- 22. 3.1.4.PMBOK
- 23. 3.1.5.Технологии управления проектами фирмы «1С»
- 24. 3.2.Введение в терминологию
- 25. 3.2.1.Проектный треугольник
- 26. 3.3.Реинжиниринг бизнес-процессов
- 27. 3.4.Какие подсистемы в какую очередь внедрять
- 28. Глава 4. Кто участвует в проекте внедрения
- 29. 4.1.1.Управляющий комитет
- 30. 4.1.2.Проектная команда исполнителя
- 31. 4.1.3.Рабочая группа со стороны заказчика
- 32. 4.2.Мотивация участников проекта внедрения
- 33. 4.2.2.Модели мотивации
- 34. 4.3.Коммуникация и конфликты
- 35. 4.3.1.Удаленное взаимодействие
- 36. 4.3.2.Командообразование
- 37. 4.3.3.Управление конфликтами
- 38. Глава 5. Этапы и документация проекта
- 39. 5.2.Документация проекта
- 40. 5.3.Фазы проекта
- 41. 5.3.2.Анализ и концептуальное проектирование
- 42. 5.3.3.Дизайн архитектуры системы
- 43. 5.3.4.Разработка
- 44. 5.3.5.Опытная эксплуатация
- 45. 5.3.6.Ввод в промышленную эксплуатацию
- 46. 5.3.7.Закрытие проекта
- 47. Глава 6. Что анализировать и как настроить прототип системы
- 48. 6.2.Готовим отчет
- 49. 6.3.Приоритизация требований
- 50. 6.4.Описание бизнес-процессов
- 51. 6.4.1.Функциональные блок-схемы
- 52. 6.4.2.IDEF0
- 53. 6.4.3.EPC
- 54. 6.4.4.BPMN
- 55. 6.4.5.Особенности описания бизнес-процессов
- 56. 6.5.Прототип и его демонстрация
- 57. Глава 7. Как оценить срок и бюджет проекта
- 58. 7.2.Методы оценки трудозатрат
- 59. 7.2.2.Анализ предложений исполнителей
- 60. 7.2.3.Оценка «снизу вверх»
- 61. 7.2.4.Оценка «сверху вниз»
- 62. 7.2.5.Экспертная оценка
- 63. 7.2.6.Параметрическая оценка
- 64. 7.2.7.Оценка по трем точкам (метод PERT)
- 65. 7.3.Мифический человеко-час
- 66. 7.4.Расчет себестоимости человеко-часа
- 67. 7.5.Как получить итоговый срок проекта
- 68. Глава 8. Риски проекта и управление ими
- 69. 8.2.Какие риски бывают в проекте внедрения ERP-системы
- 70. 8.3.Профилактика и как бороться с проявлениями рисков
- 71. 8.4.Когда риски можно игнорировать
- 72. 8.5.Процедура управления рисками в проекте внедрения ERP-системы
- 73. Глава 9. Как пережить фазы разработки и опытной эксплуатации
- 74. 9.2.Стандарты разработки
- 75. 9.3.Тестирование
- 76. 9.4.Готовимся к обучению пользователей
- 77. 9.5.Опытная эксплуатация
- 78. 9.6.Ведем список запросов на изменение
- 79. Глава 10. Запуск системы и что дальше
- 80. 10.2.Система продолжает работать – сопровождение корпоративной системы
- 81. Заключение
- 82. Список использованной литературы
Комментариев: 0