И так, Вы задумались о внедрении новой корпоративной системы в Вашем бизнесе. Это может быть учетная система, система согласования документов, автоматизация бухгалтерии, или даже автоматизация принятия простых решений на основе данных. На верхнем уровне, это не так уж и важно - самой большой проблемой всегда остается проблема белого листа. Так с чего же начать?
В этой статье я постараюсь систематизировать накопленный нами опыт и ответить на вопрос, как же сделать первые шаги в проекте по автоматизации Вашего бизнеса.
А Вам точно нужна автоматизация?
Мы всегда начинаем именно с этого вопроса. Как ни странно, но в нашей практике есть достаточно много случаев, когда мы отговариваем клиентов от внедрения новой системы, поскольку на самом деле она им не нужна. Ну, или не нужна в том виде, в котором они ее себе представляют.
Наиболее типичными проблемами, решением для которых является автоматизация, являются:
Сложно контролировать прохождение бизнес-процесса. Задачи застревают, документы теряются, и в итоге получается непредсказуемый и сложно контролируемый результат.
Люди ошибаются и ошибки стоят Вам денег и времени. Самое худшее, что даже на поиск ошибок уходит достаточно много времени, а в итоге управление компанией или отделом выливается в микро менеджмент, что отнимает время у руководства и не позволяет масштабировать бизнес.
Невозможно отследить продуктивность каждого отдельного сотрудника, или даже просто поставить KPI. Во многих компаниях награждение сотрудников происходит не на основе эффективности их работы, а на основе того, насколько активно они изображают деятельность, и насколько их движения заметны руководству. А в итоге мы получаем неэффективный процесс, низкую мотивацию, а так же полное непонимание сотрудниками целей компании.
Операции выполняются не эффективно. Сотрудники бегают по отделам в поисках нужных людей, документы копятся на столах находящихся в отпуске сотрудников, а Вы сами не всегда знаете, на каком этапе процесса происходят задержки.
На производстве возникают простои или излишние запасы. Это приводит к значительным издержкам и повышению итоговой себестоимости. При этом руководство может не всегда понимать, где же искать проблему, не говоря уже о том, как же ее решить.
Невозможно отследить историю работы с каждым отдельно взятым клиентом. А значит невозможно повышать качество клиентского сервиса и даже просто отследить, из-за чего компания теряет клиентов и деньги.
Отчеты делаются раз в месяц, содержат ошибки и не дают прозрачной картины. Во многих компаниях на подготовку отчетов тратится до 20% времени руководителей и сотрудников. А ведь это кошмарные потери в деньгах, не говоря уже о том, что лучшие сотрудники могут потерять мотивацию из-за бесконечной рутины и даже покинуть компанию. Важно и то, что отчеты могут содержать ошибки или даже преднамеренные искажения, что может привести к принятию неверных и опасных для компании решений. Ну а кроме того, решения принимаются слишком поздно, а потому компания стремительно теряет свою конкурентоспособность на быстро меняющемся рынке.
Этот список конечно же не закрытый, однако я попытался собрать в нем самые часто встречающиеся боли приходящих к нам клиентов.
Я вряд ли написал здесь что-то принципиально для Вас новое. Но вот что интересно: А сможете ли Вы оценить влияние этих факторов на Ваш бизнес? Сколько конкретно денег Вы теряете?
А ведь от ответа на этот вопрос зависит не только то, нужна ли Вам учетная система, но и каков бюджет на ее разработку.
Предлагаю воспользоваться простым и понятным инструментом, который применяем у себя мы.
Советы по заполнению:
будьте максимально конкретны - Не надо писать "Внедрим отчетность в отделе продаж"... Гораздо полезнее будет написать "Создадим визуализацию воронки продаж, с возможностью посмотреть ее в разбивке по сегментам клиентов, а так же по сотрудникам отдела продаж".
Всегда думайте о количественных показателях. Основная задача упражнения - понять, сколько денег вы предположительно теряется не внедрив систему, а значит и оценить целесообразный бюджет на ее внедрение.
Будьте реалистичны. Крайне маловероятно, что внедрение новой CRM системы даст Вам прирост продаж на 100% за первый же месяц.
Всегда думайте о том, каким образом Вы сможете проверить гипотезу. Не стоит указывать те метрики, которые Вы не сможете посчитать.
В рамках данного упражнения, вы не просто пропишете, почему для Вас важно внедрение системы, но и посчитаете сколько денег Вы можете на это потратить. В процессе Вы так же продумаете стратегию связанных с системой изменений. Ведь само по себе внедрение новой системы чаще всего бесполезно - люди должны начать думать и работать по другому, и только в таком случае Вы получите желаемый результат. А это уже не зависит от разработчика системы.
Какую технологию выбрать?
На рынке существует бесчисленное множество решений для автоматизации бизнеса, и одной из основных проблем является выбор наиболее подходящего именно для Вас решения.
Выбор платформы - очень важное решение, которое повлияет не только непосредственно на запланированный проект, но и на все проекты после него.
Вопрос в том, что чем более гибкой и расширяемой является платформа, тем дороже Вам обойдется ее внедрение. И наоборот - чем дешевле система, тем выше вероятность, что Ваша компания просто перерастет ее возможности в течении нескольких последующих лет.
Попробуем классифицировать все существующие решения автоматизации на 4 основных типа:
MVP с использованием существующих инструментов.
Коробочные решения.
Low-code платформы.
Платформы требующие разработки.
У каждой из этих категорий есть свои преимущества и недостатки, и выбор зависит от степени зрелости компании и конкретного процесса, а так же маржинальности.
В нормальной ситуации, бизнес проходит путь от первого решения и до третьего или четвертого с каждым крупным блоком процессов, меняя используемые решения по мере своего роста и развития.
MVP с использованием существующих инструментов
С этого все начинается.
При появлении нового процесса в компании (или при создании самой компании), чаще всего процесс начинается с таблицы в Google sheets (или в Excel), а так же небольшого стандарта по тому как с ней работать.
В некоторых случаях, в компании даже есть технически подкованный специалист, который может пойти дальше и разработать решение на основе Access, Sharepoint, Google Forms, VBA скриптов под Excel или более продвинутых инструментов вроде Power Apps от Microsoft. Конечно же это только неполный список наиболее популярных решений, но думаю общий смысл понятен.
Далеко не всегда эти решения удобны в работе, и еще реже - защищены от пользовательских ошибок или даже злонамеренных искажений в отчетности или других диверсий.
Но важность этой стадии невозможно переоценить, ведь именно она позволяет путем проб и ошибок сформировать четкое понимание того, как Вы хотите работать, и что наиболее продуктивно именно для Вашего бизнеса.
В какой-то момент решение теряет свою эффективность, и причин может быть много:
Расчеты становятся слишком тяжеловесны для таблицы или данные уже просто не помещаются в нее.
Большое количество пользователей мешают друг другу при одновременной работе.
Появляется необходимость в разграничении доступов к критически важным данным.
Отследить ход исполнения процесса невозможно, ведь пользователи просто забывают вносить данные, или не делают этого вовремя.
У руководства уходит очень много времени на подготовку сводной отчетности, а ее качество вызывает серьезные сомнения.
Ну и т.д.
В этот момент стоит задуматься о переходе на следующую стадию автоматизации.
Коробочные решения
Это только вторая стадия автоматизации, и потому подобные решения обычно заточены под малый и средний бизнес. Ну либо под какие-то очень стандартные процессы, вроде кадрового делопроизводства, которые может использовать бизнес любого размера, поскольку они жестко регламентированы законодательством.
В коробочных решениях применяются лучшие отраслевые практики, а потому чаще всего подобные решения подходят фактически любой компании и работают лучше чем самодельные "пробные" решения.
Что характеризует любые коробочные решения?:
Быстрое и дешевое внедрение. Часто их можно настроить даже самостоятельно без привлечения специалистов.
Низкая степень кастомизации. Вам придётся подстраивать свои процессы под то, что реализовано в данной системе. Будьте готовы к тому, что Вы не сможете настроить систему под себя, ибо подобные системы обладают только минимальными настройками.
Невозможность доработки системы. Даже если Вы будете готовы платить за изменения в системе, чаще всего это принципиально не возможно будет сделать. Поэтому если Вы переросли подобную систему, то от нее скорее всего придётся отказаться.
Очевидно, что в процессе дальнейшего роста, большинство компаний перерастают подобные решения. Наиболее частыми признаками того что это произошло и в Вашей компании, являются:
Появилось большое количество табличек в Google sheets, которые восполняют недостающий в "коробке" функционал.
Появляется большое количество неавтоматизированных операций по ручному переносу данных из одной системы в другую.
Растет количество стандартов и устных договоренностей по выполнению определенных операций, которые просто не предусмотрены коробочным решением или же реализованы не совсем удобно для Вас.
Вам уже недостаточно разрозненных отчетов в каждой отдельной системе, ведь они не дают полной картины. Вам нужна сводная отчетность, а собрать ее из различных систем практически невозможно.
Если Вы стали замечать подобные симптомы, значит скорее всего пора переходить на следующий уровень.
Low-code платформы
Low-code платформы получили широкое распространение относительно недавно, и сейчас растут совершенно потрясающими темпами. Внедрение подобных платформ является одним из основных трендов в ИТ индустрии, поскольку их внедрение требует минимального участия столь недешевых разработчиков.
Тем не мене, важно понимать, что low-code платформы - это всего лишь коробочные решения, просто с очень большим количеством функционала и вариантов его настройки.
От коробочных решений их отличает следующее:
Дорогое и трудозатратное внедрение за счет:
Необходимости большого количества настроек.
Привлечения дорогостоящих консультантов, а иногда и разработчиков.
Высокой стоимости лицензий.
Существенно больших возможностей по кастомизации. Обычно эти системы можно настроить под потребности практически любого бизнеса, однако:
Большое количество настроек означает, что настраивать нужно практически все. Если в коробочном решении Вы можете приступать к работе сразу после регистрации, то с Low-code платформами Вам придётся настраивать процессы и структуры данных, а для этого нужны соответствующие специалисты.
Даже если в системе уже есть пред настроенные процессы, в 90% случаев они Вам не подойдут, и их так же придётся настраивать.
И тем не менее, возможности по кастомизации все же существенно ограничены, и рано или поздно Вы обязательно наткнетесь на что-то, что не сможете обойти в рамках подобного решения.
К выбору Low-code платформы необходимо подходить очень осторожно, и не в коем случае не рассчитывать только на рекламные тексты и ролики в youtube. На раннем этапе необходимо сформировать список требований к системе и привлечь специалистов по предлагаемым решениям, чтобы они помогли Вам разобраться в том, что из Ваших пожеланий может оказаться невозможным реализовать в рамках той или иной платформы. На старте проекта, всегда помните, что когда Вы закупите сотню лицензий и потратите несколько месяцев на настройки системы, будет уже поздно отказываться от нее из-за того, что часть пожеланий все же не удается реализовать.
Проблемой тут является то, что компании продающие low code платформы или их внедрение кровно заинтересованы в их продаже, и вряд ли с готовностью расскажут Вам о потенциально высоких рисках, даже в том случае, если будут знать о них с самого начала. Ведь в середине проекта Вы уже скорее всего не откажетесь от текущего решения и можно будет вместе поискать допустимые компромиссы.
Требующие разработки платформы
Альтернативной Low-code платформам является разработка решения с помощью разработчиков, как иногда говорят - "с нуля".
Однако важно понимать, что "с нуля" является очень серьезной ошибкой мышления, которая заставляет думать что подобная разработка будет стоить очень дорого. В большинстве случаев это совсем не так.
В современном ИТ мире уже практически ничего не разрабатывается с нуля:
Настроить простенькую таблицу для работы с данными на основе существующих бесплатных шаблонов - это дело буквально одного дня.
За несколько дней можно и внедрить в разрабатываемую систему стандартные движки настройки бизнес-процессов.
Не говоря уже о том, что у любой компании, которая занимается разработкой учетных систем есть огромное количество наработок, и в большинстве случаев они неоднократно пере используются.
Подумайте так же и о том, что в большинстве случаев Вы никогда не воспользуетесь 80% функционала доступного в low-code платформе, но Вы платите за этот функционал, оплачивая стоимость лицензий годами. Разработка же требует серьезных вложений в начале, но потом затраты резко падают.
Ключевые отличия разработки от Low-Code:
Вы получаете только необходимый Вам функционал, и именно в нужном Вам виде.
Разработка стоит дороже и занимает в среднем больше времени. Зато и перерасти такую систему почти невозможно, поскольку она будет изменяться и расти вместе с компанией - ограничений практически не существует.
Разработка корпоративных систем требует особенного подхода, а потому лучше выбирать экспертов именно в этой области. Ведь есть очень большая разница между разработкой игры для смартфона (или новостного приложения), и финансовой учетной системы.
И разница тут не только в экспертизе в конкретной предметной области, но и в совсем другом подходе к разработке самого решения.
Теперь когда Вы определились с технологиями, настало время поговорить о подходе к организации проекта. На эту тему написан не один учебник, и в рамках данной статьи я попробую дать только быстрый обзор существующих подходов, а так же расскажу об их преимуществах и недостатках.
Waterfall
Waterfall - это самый старый (и интуитивно понятный) подход к разработке программного обеспечения, и назван он так из-за напоминающих водопад диаграмм Ганта.
Этот подход знаком каждому менеджеру, поэтому на нем останавливаться подробно мы не будем. Скажу только, что Waterfall не просто не эффективен, но и очень опасен. Он дает иллюзию того, что что-то пойдет по плану и в рамках бюджета / спланированного плана работ... Но это не так.
Разработка программного обеспечения является гибкой по своей сути. И единственное, что мы знаем точно - это то, что все будет меняться, и меняться довольно быстро. Причин тут много:
Изменчивая внешняя рыночная среда.
Работа конкурентов.
Постоянно изменяющееся регулирующее законодательство.
Бизнес-процессы компании так же не стоят на месте - по данным исследований, требования меняются примерно на 5%-6% каждый квартал. А на динамичных рынках или в быстро растущих компаниях скорость изменений может быть и в два раза быстрее.
Поэтому план - это только иллюзия, которая мешает проектной команде оперативно реагировать на изменения и создавать тот продукт, который Вам действительно нужен.
Применяющая Waterfall компания выделяет бюджет на разработку, дает подрядчику требования, и через определенное количество месяцев подрядчик возвращается с готовым решением, которое более или менее соответствует заявленным требованиям.
Но даже если и забыть и тех изменениях которые произойдут за данный период, все-равно представить себе даже относительно небольшую систему во всех деталях невозможно, а значит неизбежно возникает большое количество недопониманий и нюансов, приводящих в итоге к тому, что системой пользоваться невозможно, хотя формально она соответствует заявленным требованиям.
В этот момент начинаются проблемы, конфликты, и в некоторых случаях Вы можете остаться и без системы, и без денег. Либо же на доработку системы придётся выделить дополнительный бюджет, который может даже и превышать изначально запланированный - ведь стоимость доработок растет с ростом самой системы.
Гибкая проектная разработка
Гибкая разработка подразумевает реализацию более или менее четко обрисованного объема работ в рамках согласованных сроков. Однако работа не планируется с самого начала - она разбивается на двухнедельные итерации, каждая из которых планируется и оплачивается отдельно. Результат предоставляется в конце каждой двух недельной итерации (спринта), однако некий общий план всего проекта все же есть.
Одной из основополагающих идей здесь является "Железный треугольник проекта".
Если при Waterfall, все три угла треугольника стороны пытаются зафиксировать с самого начала, то при гибком подходе всегда фиксируется только либо содержание, либо бюджет и сроки. И никогда не фиксируется и то и другое сразу, иначе подход сразу же теряет свою гибкость.
Ключевым отличием от Waterfall является то, что команда показывает результат своей работы каждые две недели, что позволяет создать короткую петлю получения обратной связи, а значит максимально быстро:
Прояснять все недопонимания.
Корректировать ход проекта в случае изменений.
Вспоминать о забытых изначально нюансах.
Тем не менее, внесение этих изменений и корректировок требует времени и денег. А значит, не имеет смысла доводить какой-то отдельно взятый функционал до идеала - ведь в таком случае бюджет скорее всего закончится до того, как будет реализован весь желаемый функционал. Очень важно сначала создать минимально достаточную реализацию желаемого функционала, решающего все основные проблемы стоящие перед проектом, а потом уже (если останется бюджет), устранять оставшиеся шероховатости.
Основной проблемой традиционного гибкого подхода остается, как ни странно, его недостаточная гибкость. Это связано с тем что в большинстве случаев подход к коммуникации и сбору требований все же остается прежним.
Команда конечно не пишет ТЗ сразу на весь продукт и разрабатывает частями по ходу проекта. Но тем не менее, на разработку ТЗ даже на один модуль может уходить 2-4 недели, что существенно замедляет проект и оставляет часть рисков в плане недопониманий.
Продуктовая разработка
Одной из ключевых ошибок менеджмента, которую мы встречали практически на каждом проекте, является следующее: ТОП менеджеры часто уверены в том что они знают работу своих подчиненных во всех деталях, и отлично знают все существующие в их зоне ответственности бизнес-процессы. И что хуже, многие считают отклонения от этих процессов чем-то плохим... Ошибками которые нужно устранить.
Но правда в том, что в ежедневной работе любой компании есть огромное количество недопониманий, обходных путей, исключений, которые абсолютно необходимы в работе. Если бы это было не так, то большинство сотрудников уже сейчас можно было бы заменить роботами / компьютерными программами.
Поэтому исключать рядовых сотрудников из проекта ни в коем случае нельзя, ведь именно они знают, как все работает на самом деле. Но как это сделать?
Рядовых сотрудников очень много, и для того чтобы выяснить все детали зачастую требуется вовлечь в проект чуть ли не всю компанию, а это не возможно.
Рядовые сотрудники часто не заинтересованы в автоматизации, ведь она может усложнить им жизнь, да и просто никто не любит изменений.
В ряде корпоративных культур, рядовые сотрудники бояться рассказывать о некоторых упрощающих им жизнь обходных путях, поскольку боятся гнева начальства.
Второй серьёзнейшей проблемой является очевидность. Точнее не сама очевидность, а то, что человек склонен считать очевидное для себя, очевидным и для других. А это совсем не так.
Результатом является то, что когда сотрудники получают работающий продукт, они чаще всего замечают очевидные для них недоработки или ошибки, которые не были упомянуты в техническом задании именно в силу их очевидности. И вот здесь могут начаться конфликты, ведь систему надо переделывать, а эти нюансы не были заложены в изначальный бюджет.
Эти ошибки мышления часто приводит к провалам проектов на этапе разработки или внедрения. Это как раз и есть одна из основных проблем Waterfall подхода - когда сотрудники получают новую систему, очень часто оказывается, что в ней просто невозможно работать, поскольку в ней реализован только основной сценарий работы, который может не подходить к примерно 30% - 50% реальных жизненных ситуаций.
Решить эти проблемы и призван продуктовый подход к разработке учетных систем.
Этот подход пришел к нам из силиконовой долины. Подумайте, ведь разработчики paypal или Telegramm, точно так же не могут вовлечь всех своих клиентов в разработку своих продуктов, однако обязаны учитывать их интересы, даже те, в которых клиенты могут сами не отдавать себе отчета.
Методология продуктовой разработки подразумевает экспериментальный подход к разработке ПО. Мы расскажем о нем в отдельных статьях, однако основные идеи таковы:
Любое знание - это только гипотеза, которая требует проверки. И только после проверки гипотеза может считаться верной.
Пользователи очень плохо предсказывают будущее. Пользователи могут рассказывать Вам только об уже возникавших у них проблемах, но не о своем поведении в гипотетической ситуации.
Пользователи не могут оценить новую идею до того как увидят и прочувствуют ее на опыте.
Все решения должны приниматься на основе полученных экспериментальным путем данных.
Несмотря на свою непривычность и даже некоторую контр интуитивность, именно этот подход показывает наибольшую эффективность в любой разработке программного обеспечения, начиная от сложнейших систем искусственного интеллекта и заканчивая мобильными приложениями для заказа пиццы.
Команды использующие продуктовый подход создают MVP (Minimal Valuable product) на каждый функциональный блок отдельно, а не для всей системы целиком. Это позволяет решать проблемы одну за одной, и проводить эксперименты с использованием реально работающего ПО на сотрудниках компании, быстро получая обратную связь и корректируя направление движения.
Используя этот подход, вполне реально запустить часть будущего продукта в промышленную эксплуатацию уже в течении первого месяца проекта!
В конце этого раздела, хочу еще раз подчеркнуть, что не важно какой подход Вы выберите. Самое главное - всегда помнить о том, что ни один ИТ консультант не знает Ваш бизнес так же хорошо, как знаете его Вы. Вообще никто не знает Ваш бизнес так же хорошо как Вы! Поэтому если Вы начинаете проект по автоматизации, необходимо быть готовым к серьезным временным и трудозатратам с Вашей стороны. Именно недостаточная вовлеченность бизнеса в проекты автоматизации является основной причиной их провалов.
Оценка эффективности проекта
Итак, новая система сдана, и сотрудники приступили к работе в ней. Но как понять, успешен ли был проект?
На него были потрачены серьезные средства и много времени менеджмента и рядовых сотрудников. Сделал ли этот проект Вашу компанию лучше и эффективнее? Когда окупятся сделанные инвестиции?
Оценивать эффективность проектов очень важно, поскольку это дает возможность проанализировать сделанные ошибки (которых всегда хватает), а так же стать умнее как компания, сохранить сделанные выводы в базу знаний, и не допускать те же самые ошибки в дальнейшем.
К сожалению, чаще всего проект считается успешным в том случае, если не сильно вышел за рамки бюджета и запланированных сроков. Поэтому здесь мне хотелось бы сказать пару слов важности оценки финансовых результатов, а так же о документации извлеченных уроков.
Оценка финансовой эффективности проекта
Помните таблицу с гипотезами из самого первого раздела этой статьи? Это и есть первый и самый важный шаг в оценке финансовой эффективности проекта.
Очень рекомендуем провести те измерения, которые были запланированы, чтобы понять, достигли ли Вы тех результатов, которых хотели добиться в самом начале. Это не только поможет Вам лучше понять результаты проекта, но и в целом поможет стать компании лучше.
Чаще всего реальность не совпадает с ожиданиями (причем нередко и в лучшую сторону), и очень важно осознать причины. Этот процесс поможет Вам:
Понять эффективность проекта и оценить его результаты.
Повысить мотивацию команды проекта.
Понять, стоит ли финансировать дальнейшее развитие данной системы.
Подготовить обоснование для дальнейшей автоматизации других областей Вашего бизнеса.
Лучше понять Ваш бизнес и принципы его работы.
Проанализировать причины недостаточного роста определенных показателей и понять существующие проблемы. Довольно часто они лежат не в области автоматизации.
Поддержать привычку принимать решения на основе данных.
Так же полезно бывает и собрать обратную связь от сотрудников. Иногда проекты могут приносить очень неожиданную пользу. Например, один из наших клиентов признался нам, что одна только небольшая фича окупила все вложенные в проект средства всего за три месяца работы, причем об этом эффекте даже и не думали в начале проекта! Дело было в том, что мы по ходу дела (это не было основной целью) устранили дыру в безопасности, лишив тем самым некоторых партнеров компании-клиента возможности получать необоснованную прибыль за счет средств нашего клиента. Наш заказчик даже и не думал, что у них фактически крали деньги...
Документация извлеченных уроков
Так же важно документировать основные ошибки и пути их избегания в будущем, а так же обеспечить сохранение полученных знаний и доступность их для всех сотрудников компании. Хотя бы для тех, которые занимаются ИТ проектами.
Если вы не делаете этого сейчас, то можно начать с чего-то подобного:
Дата внесения записи | Проект | Возникшая проблема | Имевшие место последствия | Что мы сделаем, чтобы не допустить такого в будущем? |
Так же полезно и проведение "Разбора полетов" после завершения проекта. На подобных разборах обычно обсуждаются следующие вещи (список не закрытый):
Что мы сделали лучше по сравнению с предыдущим проектом?
Какие основные ошибки мы допустили, и что мы сделаем, чтобы не допускать их в дальнейшем?
Разработать план действий по недопущению возникших ошибок в дальнейшем и назначить ответственных за его реализацию.
Поблагодарить команду проекта за проделанную работу.
Тут очень важно не критиковать и не наказывать, иначе в следующий раз ошибки будут от Вас просто прятать. Задача состоит именно в том, чтобы понять, как такое могло произойти (и что же собственно произошло), и поменять процессы таким образом, чтобы этого просто не могло произойти в дальнейшем.
В заключении, хочу пожелать всем успехов в Ваших проектах и развитии бизнеса. Ведь по данным Monday.com, 54% офисных сотрудников в США все еще тратят 5 или более часов в неделю на абсолютно рутинные задачи, а 16% - более 10 часов! Не думаю, что у нас ситуация сильно лучше, а значит - практически любой бизнес в ближайшие годы ждет хотя бы один проект по автоматизации.
