Для провайдеров управляемых услуг документация — это не просто «приятно иметь», а продукт. С Trupeer вы можете сэкономить часы на подготовке документации MSP, начав с бесплатных шаблонов документации MSP, настроив их с помощью ваших бренд-гайдлайнов и превращая клиентскую документацию в видеоруководства, которыми может пользоваться любой техник.

Что такое документация MSP и чем она отличается?

Документация MSP — это всё, что провайдер управляемых услуг фиксирует, чтобы управлять технологиями других организаций: реестры активов, схемы сетей, учетные данные, инструкции (runbooks), маршруты эскалации, специфические особенности клиентов, а также отчеты и обзоры, которые видит клиент.

Две вещи делают ее структурно отличной от внутренней ИТ-документации, и почти каждый шаблон игнорирует обе.

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

И вы документируете одну и ту же процедуру сразу для множества инфраструктур. Внутренняя команда пишет один runbook по восстановлению из резервной копии. MSP пишет один — и затем должен поддерживать его актуальность в тридцати или сорока средах, которые отличаются так, что никто полностью не помнит всех нюансов.

Вторая проблема — та, которая тихо «съедает» маржу MSP, поэтому именно с нее начинается эта страница. Для версии, рассчитанной на одну инфраструктуру, наш шаблон ИТ-документации покрывает общий случай.

Почему сорок копий одного runbook — это реальная проблема

Почти каждый MSP начинает одинаково. Соберите хороший набор runbooks. Подключите клиента. Скопируйте runbooks в папку или пространство этого клиента, чтобы инженер, работающий с тикетом, имел всё в одном месте. Повторите.

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

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

То, что делают инженеры дальше, — самая дорогая часть. Когда техника дважды «обжигают» runbook, который не соответствует среде, они перестают читать runbooks. Вместо этого они работают от базовых принципов — это дольше, менее последовательно и полностью невидимо в ваших отчетах, потому что тикет всё равно закрывается.

Поэтому структура документации MSP должна обеспечивать стандартное обновление в одном месте. Всё ниже следует из этого.

Как настроить этот шаблон в Trupeer

Шаг 1: Откройте раздел Templates

Перейдите в раздел Templates из главной навигации.

Шаг 2: Выберите и откройте шаблон

Нажмите на любой шаблон, с которым хотите работать, чтобы открыть его.

Шаг 3: Разверните просмотр шаблона

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

Шаг 4: Отредактируйте шаблон

Нажмите Edit, чтобы начать изменять выбранный шаблон.

В редакторе вы можете:

• Добавлять новые разделы

• Задавать или обновлять правила форматирования

• Добавить логотип и настроить его положение и связанные параметры

Шаг 5: Сохраните настроенный шаблон

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

Шаг 6: Предпросмотр и точная настройка шаблона

Когда вы захотите увидеть, как выглядит ваш настроенный шаблон, откройте Preview.

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

С шаблонами документации MSP вы можете:

• Экономить часы на написании: пропускайте пустую страницу — структуры уже собраны под операции MSP.

• Сокращать MTTR: понятная документация помогает любой службе поддержки быстро работать с любым клиентом.

• Оставаться в фирменном стиле: применяйте логотип, шрифты и цвета с помощью бренд-набора Trupeer.

• Быстрее подключать техников: новые специалисты быстрее выходят на рабочий режим с помощью четких документов на основе видео.

• Быть готовыми к аудитам: встроенные разделы поддерживают SOC 2, ISO 27001 и аудиты клиентов.

• Достигать глобальных команд: переводите документацию MSP на 65+ языков в один клик.

Отличная документация MSP — это то, что делает бизнес управляемых услуг масштабируемым. Используйте эти шаблоны, чтобы четко и последовательно фиксировать каждого клиента, каждую систему и каждую процедуру.

Документируйте стандарт один раз, фиксируйте только отклонения

Одна библиотека стандартов. Одна копия каждого документа. Версионируется, принадлежит вам и является единственным местом, где существует метод.

А затем для каждого клиента — один короткий документ, который фиксирует, где этот клиент отличается от стандарта, и ничего больше. Не копия runbook с правками. Список исключений.

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

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

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

Реестр отклонений клиента и что в него входит

Одна строка на каждое отклонение, пять полей.

Что отличается. Указывается относительно стандарта, поэтому «резервное копирование — Datto, а не наш стандарт Veeam», а не «использует Datto».

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

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

С какого момента и когда пересматривается. Дата. Отклонения, унаследованные при подключении, часто сохраняются годами, потому что никто к ним не возвращается.

Трудозатраты или риск. Короткая заметка о том, сколько это вам стоит. Именно это превращает реестр не только в технический, но и в коммерческий документ.

Добавьте заголовок с названием клиента, версией библиотеки стандартов, относительно которой составлен этот реестр, и владельцем аккаунта. Пересматривайте реестры ежеквартально. Отклонения без причины и без стоимости — кандидаты на стандартизацию, и обычно это самая высокая отдача в документационной работе, которую MSP может сделать.

Какие документы MSP действительно нужны по категориям

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

Два из этих пунктов имеют собственные шаблоны, которые стоит использовать напрямую. Учетные данные и инвентаризация лицензий естественно размещаются в нашем реестре приложений и учетных данных, а сами runbooks следуют структуре нашего шаблона ИТ SOP.

Бесплатные шаблоны документации MSP: библиотека стандартов для сборки

Скопируйте отсюда. Это минимальная библиотека стандартов, и она меньше, чем ожидает большинство MSP.

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

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

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

Инциденты и изменения. Формат пост-инцидентного обзора и формат метода процедуры для плановых изменений в инфраструктуре клиента.

Отчеты для клиента. Ежемесячный отчет, квартальный бизнес-обзор и результат аудита площадки. Фиксированный формат, данные клиента заполняются.

Пакет для отключения. Что получает клиент, что вы сохраняете, в каком формате и к какому сроку. Написано до того, как это понадобится.

Шаблон реестра отклонений. Пять полей выше.

Скопируйте сюда. Десять–пятнадцать runbooks плюс шесть постоянных документов — это рабочая библиотека. Инстинкт сначала написать сорок runbooks — причина того, что большинство проектов документации MSP «застревают» во втором месяце.

Внутренняя и внешняя документация MSP и кто чем владеет

Главное различие, которое обычно проводят, — это внутренняя документация vs документация для клиента, что полезно для выбора тона. Более важное различие — владение, и оно становится реальным при отключении.

В целом, и это зависит от договора и юрисдикции, данные клиента — это данные клиента: реестры активов, описывающие его оборудование, топологию его сети, его учетные данные, его права на лицензии, его конфигурацию. Вы храните это как сервис-провайдер, а не владеете этим.

Ваш метод — ваш: стандартные runbooks, форматы отчетов, ваши стандарты сборки, ваша модель ценообразования, ваши внутренние процедуры. Клиент, который уходит, не имеет права на вашу библиотеку runbooks.

Реестр отклонений занимает неудобное промежуточное положение, поэтому стоит прямо назвать его в договоре. Он описывает среду клиента — а значит, аргумент в пользу «его», — но он написан относительно ваших стандартов — а значит, аргумент в пользу «вашей» версии.

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

MSP с 1 360 документами и девятью устаревшими runbooks

Thornbury IT оказывала управляемые услуги тридцати четырем клиентам с двадцатью двумя сотрудниками, девять из них — инженеры. На каждом подключении они копировали набор runbooks в пространство нового клиента, что к четвертому году означало примерно сорок документов на клиента и около тринадцати сотен и шестидесяти в сумме.

Проблема проявилась во время инцидента. Инженер выполнял неудачное восстановление из резервной копии для одного клиента, следуя restore runbook этого клиента, в котором использовалась конвенция именования задач Veeam. Клиент перешел на другой продукт резервного копирования четырнадцать месяцев назад. Стандартный runbook был обновлен. Копия в папке этого клиента — нет.

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

Измеримая стоимость была во времени обработки. Среднее время обработки второго уровня по компании составляло сорок семь минут. Для клиентов с устаревшими runbooks — семьдесят одна минута, потому что инженеры по этим аккаунтам перестали доверять документации и каждый раз разбирались заново.

Отдельно: в третьем году один клиент ушел и запросил свою документацию. Thornbury отправила папку клиента, в которой были их собственные стандартные runbooks, смешанные с реестром активов и учетными данными клиента. Никто никогда не проводил четкую границу. Спор о том, на что клиент имеет право, занял шесть недель и включал юристов обеих компаний.

Пересборка заняла месяц времени одного человека. Одна библиотека стандартов, одна копия, с версионированием. Для каждого клиента — только реестр отклонений. Медианная длина реестра — одиннадцать строк.

Тринадцатьсот шестьдесят документов превратились в сорок стандартных документов и тридцать четыре реестра, то есть всего семьдесят четыре. Время обработки второго уровня сошлось к сорока четырем минутам по всем аккаунтам. А пакет для отключения был определен в договоре с этого момента: клиент получает реестр активов, учетные данные, схемы и свой реестр отклонений, а Thornbury сохраняет библиотеку стандартов.

Есть ли бесплатные шаблоны документации MSP на GitHub?

Да, и на них стоит взглянуть с реалистичными ожиданиями.

Вы найдете репозитории сообщества с коллекциями runbooks, библиотеки PowerShell-скриптов со встроенной документацией, фреймворки документации на основе markdown и иногда — полную структуру документации, опубликованную MSP в рамках рекрутинга или маркетингового проекта. Поиск runbooks MSP или ИТ-документации вместе с markdown или docs-as-code покажет большую часть этого.

Что действительно полезно в таких репозиториях — это структура и охват: список runbooks, который поддерживает компетентный MSP, — хороший чек-лист для вашей собственной базы. А вот контент обычно редко бывает полезным, потому что runbooks зависят от набора инструментов, а процедура восстановления для чужого продукта резервного копирования и RMM ближе к «разобранному примеру», чем к шаблону.

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

Сам подход docs-as-code, то есть markdown в системе контроля версий, — легитимный вариант для MSP, и он элегантно решает проблему единственной копии. Его слабое место в том, что инженеры под давлением времени не будут коммитить в репозиторий, поэтому ограничивающим фактором становится не инструментарий, а принятие подхода.

ПО для документации MSP и проблема vendor lock-in

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

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

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

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

Что происходит с документацией, когда клиент уходит?

Отключение — это момент, когда качество документации становится заметным, обычно тем, кто уже недоволен.

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

Задайте сроки и формат в той же оговорке, потому что «документация будет предоставлена» — это то место, где начинаются споры. Тридцать дней и указанный формат — это нормально.

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

Если уход — это передача другому провайдеру, а не «своими силами», структурированная передача обходится существенно дешевле, чем «вываливание» документов, и наш SOP по передаче знаний описывает, как это сделать.

Могу ли я получить шаблоны документации MSP в PDF?

PDF подходит для двух из них и не подходит для остальных.

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

Не подходит для runbooks, реестра отклонений и реестра активов — всё это меняется, и всё должно быть доступно для поиска. Библиотека runbooks в PDF — это более медленная версия проблемы из приведенного выше примера, потому что PDF не может сказать читателю, что он устарел.

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

Как поддерживать библиотеку стандартов актуальной для каждого клиента

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

Trupeer AI убирает большую часть этого. Инженер выполняет задачу один раз на видео, а результат — это отформатированный runbook с уже готовыми шагами и экранами, который можно сразу проверять, а не писать с нуля. Обновление десяти runbooks превращается в день, а не в квартал.

Фиксируйте это. Оформляйте в фирменном стиле. Переводите. Делайте Trupeer.

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

Часто задаваемые вопросы

Есть ли бесплатные шаблоны документации MSP в PDF?

Структуры на этой странице можно бесплатно копировать, а разумное разделение — хранить runbooks и реестры в чем-то, доступном для поиска, а клиентские отчеты экспортировать в PDF. Нет ограниченной загрузки и нет формы. Если вам нужен PDF библиотеки стандартов для справки, сгенерируйте его из вашей актуальной копии, а не поддерживайте отдельно.

Какие лучшие бесплатные шаблоны документации MSP?

Лучший набор — самый маленький из тех, который вы сможете поддерживать актуальным: десять–пятнадцать runbooks, покрывающих ваши самые частые объемы тикетов, пакет для подключения, документ по эскалации, формат реестра отклонений и три формата отчетов для клиента. Оценивайте любую библиотеку шаблонов по тому, отделяет ли она стандарт от исключений для каждого клиента, потому что именно эта часть определяет, переживет ли она тридцать клиентов.

Где MSP должна хранить свою документацию?

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

Сколько документации новый клиент должен получить при подключении?

Никакой из вашей библиотеки стандартов и все данные по инфраструктуре клиента. На практике ценная для клиента поставка при подключении — это реестр активов, схема сети и простое резюме того, что вы нашли, и что рекомендуете. Отправлять runbooks при подключении — распространенный инстинкт, и он отдает ваш метод без коммерческой отдачи.

Клиент владеет документацией, которую мы пишем о его системах?

Обычно — да, их данные, обычно — нет, ваш метод, и границу следует прописать в сервисном соглашении, а не спорить при выходе. Реестры активов, схемы, учетные данные и конфигурация описывают их собственность. Ваши стандартные runbooks и форматы отчетов — это ваша интеллектуальная собственность. Попросите юриста проверить пункт, потому что позиция зависит от договора и юрисдикции.

Как нам не дать инженерам пропускать документацию?

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