Как сэкономить массу времени и денег при внедрении Асаны

Внедряла Асану для всех основных процессов дизайн-агентства из 30 человек как внутренний бизнес-архитектор. Пробовала работать с компанией-интегратором, в результате обучилась и сделала все сама, став Asana Partner. Делюсь выводами, которые пригодятся при внедрении любой системы организации работы.

Уверена, что на VC вы найдете немало кейсов по внедрению Asana, чтобы вдохновиться идеей ее внедрения. Потому что Asana – это действительно звезда, любовь, огонь и все прочие популярные слова восторга. Пусть моя статья будет подстраховкой для тех, кого не пугают новости о блокировке Асаны в России, кто уже решился на внедрение и хочет сделать это с умом.

У Asana широкие возможности. В ней можно не только вести клиентские проекты – для чего ее используют, по моему ощущению, чаще всего, – но и все прочие основные процессы компании: маркетинговые активности, HR-процессы вроде найма, онбординга, обучения, обработку финансовых запросов, внутренний IT-саппорт, регулярные собрания отделов и т.д.. И главное все это строится от цели и стратегии компании, которые также ведутся в Асане. Это отличный ресурс для системного и эффективного ведения дел компании.Поэтому даже если сейчас Асана вам нужна только для части процессов, попробуйте вести ее сразу целостно. Начните с фиксации целей компании, определите, какие активности для их достижения будут вестись в Асане, а какие в других ресурсах, как между собой эти ресурсы будут связаны и т.д. Дальше вы будете более четко понимать, в какой момент лучше начать перенос в Асану нового процесса и организовывать работу более четко.

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

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

С моей точки зрения самый большой риск при внедрении Асаны кроется в подходе “к нам придут и все настроят”. Когда еще не очень знаком с Асаной, она выглядит как большой черный (хотя нет, розовый с единорогами) ящик, к которому не ясно с какой стороны подобраться. И возникает мысль, что самим разобраться в функционале дороже, чем найти интегратора. Поэтому внутренний менеджер проекта заканчивает знакомство с программой на вводных видео и ищет компанию, которая придет и все сделает.

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

Если вы захотите переложить ответственность за внедрение Асаны на интегратора, она к вам все равно вернется. Вы же не скажете команде “это все они, интеграторы”, если в результате система будет неудобной, придется ее серьезно переделывать или она вообще не приживется?

Это ваша задача – понимать, что именно и как делает интегратор, и вовремя его сменить, чтобы не ставить проект под риск.

А еще важно понять, что внедрение Асаны – это очень индивидуальный процесс с множеством сюрпризов. При этом, бывает, что интегратор на старте за пару созвонов делает вам расчет количества часов работ, который фиксируется в договоре. Поэтому любой сюрприз, который в процессе работы будет приводить к перерасходу часов, интегратор как разумный бизнесмен, будет перекладывать на вас (“вы нас не предупредили”) или выносить за скобки (“давайте разберемся с этим позже в рамках следующего договора”). Для вас как менеджера проекта по внедрению это большие риски.

Поэтому я считаю, сотрудничество с интегратором стоит выстраивать вот так:

Внутренний менеджер проекта:

Интегратор/консультант:

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

Когда выбираешь тариф Асаны, очень хочется, чтобы все получилось максимально круто, функционально и полезно. Возникает соблазн сразу взять тариф Business (теперь он называется Advanced). Так случилось и у меня. При внедрении я составила список всех требований и хотелок команды и поняла, что только на тарифе Business мы сможем все это организовать. Купили тариф на год, а вот что случилось по факту:

Да и в принципе оказалось, что все наши процессы можно реализовывать на Premium (Starter), поэтому на следующий год перешли на него.

При выборе тарифа я общалась с двумя интеграторами – российским и международным – оба советовали тариф Business. Поэтому будьте осторожны и посоветуйтесь со специалистом, который не имеет финансовых интересов в вашем решении.

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

Ту же логику здорово использовать и в других ресурсах компании: на корпоративном диске, в базе знаний и т.д. Это сильно упростит кросс-референс между системами, а главное жизнь команды и администратора системы.

На этапе внедрения менеджер проекта много думает, рисует, просчитывает, собирает обратную связь и экспериментирует. Отсюда может создаваться ощущение, что настроить Асану так, как это будет работать годами, можно сразу при внедрении. Такое возможно только для элементарного процесса. Как бы здорово вы все не продумали, ближайшие месяцы вы будете переделывать и дотачивать – просто потому, что настройкам надо усесться, а команде нужно столкнуться со всем возможным набором рабочих ситуаций.

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

Вот что бы я делала сразу идеально это инструкции для команды по особенностям вашей Асаны. Они должны быть максимально понятными, простыми, полными и при этом находиться под рукой. Команда должна хорошо понимать общую структуру вашей системы, для чего нужны какие группы и проекты, как ими пользоваться и т.д. Если вы соберете все в одну инструкцию, людям будет гораздо сложнее, чем если разбросать подсказки внутри Асаны: внутри описания групп, в описаниях проектов, в описаниях шаблонных задач и т.д. Безусловно, у вас будет общий регламент с правилами пользования Асаной, его бы я тоже положила под руку – отдельным проектом в Асану.

Как я писала в пункте выше, ваша система будет меняться – первые месяцы активно, потом более точечно, а потом снова кардинально, потому что в бизнесе часто происходят системные изменения (изменения оргструктуры, продуктового ассортимента, культуры работы и т.д.). Важно, чтобы был человек, который следит за актуальностью всех инструкций в системе, оперативно правит и сообщает о них команде. Если система будет правиться, а инструкции не будут за всем этим поспевать, начнется хаос и рассинхрон.

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

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

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

Приведу наглядный пример с перемудриванием. У нас проводилось еженедельное собрание компании, темы обсуждения подавала команда. Ну я сделала все по красоте:

Экзамен по знанию Асаны сдала)).

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

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

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

Первые месяцы после внедрения (и дальше при онбординге новичков) старайтесь пристально следить за тем, что делает команда в системе. Это важно, чтобы увидеть неудобства в настройках. А еще, чтобы исключить ситуации, когда каждый начинает пользоваться Асаной по-своему и закрепляет это поведение, потому что никто не заметил.

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

Наблюдайте пристально за поведением в Асане пока не увидите, что привычка сформировалась:

Все, что замечаете, закидывайте сразу в план доработки системы и обучающих материалов.

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