€ 106,08
$ 100,68
¥ 13,88
Твердая почва для летящего предпринимателя
Фото: freepik.com
Треугольник в квадрат не войдет
Мне как предпринимателю близок японский принцип Poka-yoke, который, если утрированно, предполагает невозможность попадания треугольника в квадратное отверстие, несмотря на похожий размер, равно как и квадрат нельзя засунуть в круглое отверстие и т.д.
Этот принцип исключает ошибки, он, например, применяется в производстве современных автомобилей, и не только японских, - их детали проектируются таким образом, что просто невозможно поставить их неправильно.
Считаю, что этот принцип можно и нужно использовать в бизнес-процессах компании, - выстраивание организационной структуры таким образом, чтобы сама ее структура построения исключала ошибки.
Шаг первый: вся работа конкретного сотрудника должна быть завязана на одном-единственном программном решении, то есть: все отчеты, переписка, любые действия с CRM и пр. должны находиться в одном месте, это важно. Таким образом, мы избегаем ситуации, когда какая-то информация, нужная вышестоящему руководителю, например, сведения о клиентах или о действующих проектах, не может быть им оперативно извлечена.
Или, скажем, у нас на входе есть какая-то информация (допустим, в компанию по телефону обратился клиент, и в идеале все это, естественно, завязано на CRM), а на выходе - информация от сотрудника, который сделал первичный контакт, продажу, далее - выставил счет в бухгалтерию, то есть инициировал запуск другого бизнес-процесса. Таким образом, у нас все происходит в одном месте. И вот здесь смотрим на все по принципу «треугольника и квадрата». Если функционал программы выстроен правильно, то он исключает действия не по бизнес-процессу, то есть, если в ней чего-либо сделать нельзя, то мы понимаем, что сделать это невозможно. Таким образом, вы сужаете круг возможных действий - до тех, которые для вас, как для руководителя, либо собственника - архитектора бизнес процессов, желаемы.
Принцип нулевой ошибки
В большинстве компаний до сих пор «по старинке» раз в неделю проводятся планерки, на которых о своих проблемах отчитываются руководители подразделений.
Но можно ведь делать по-другому. Допустим, если у тебя в CRM «висят» без статуса клиенты, которые обратились в компанию больше чем три дня назад, представим, что ты в принципе ничего не сможешь сделать дальше в этой программе, пока не совершишь им звонок.
Так действует принцип нулевой ошибки, и при данном подходе мы смотрим на сотрудника, как на исполнителя определенной функции. Да, мы не можем повлиять в моменте на то, как он, предположим, разговаривает с клиентом, но на фактическое выполнение сотрудником того или иного бизнес-процесса влиять мы должны.
И, если мы понимаем, что вот у нас на этой точке происходит какая-то потеря информации, отчего встаёт бизнес-процесс, мы делаем компенсацию, зашиваем ее в IT-решение, которое в последующем делает эту ошибку, как ответвление от бизнес процесса, невозможной в принципе.
Архитектура гипотезы
Технологический рост любой организации – от самого маленького до большого происходит практически по одному и тому же сценарию. То есть первое время мы работаем на листочках, потом – в Excel, в Google Docs, потом мы первый раз пробуем Битрикс24, в конце концов, внедряем какой-нибудь CRM или тот же Битрикс, а некоторые компании - продукты более интересные, но и, соответственно, более сложные.
В целом же, как я считаю, любая организация в принципе должна начинаться с построения бизнес-процессов, с архитектуры хотя бы своих гипотез и предположений. И чем раньше мы внедряем IT-решения, которые выстраивают работу на основе бизнес-процессов, тем легче станет впоследствии. Потому что в организации, которая, скажем, три года проработала на Google Docs, внедрить какой-нибудь Битрикс - это уже сложная задача. Во-первых, сотрудники не любят изменений и всегда сопротивляются новому, во-вторых, скорее всего, вы не сможете сразу донести до них, что так удобнее.
Мы, например, в обеих компаниях, изначально разрабатывали программы для того, чтобы людям было удобнее работать. И было очевидно, что эти IT-продукты закрывают проблемы сотрудников, и они нас благодарили за это и сами просили добавить какой-то функционал. Но важно то, что мы очень давно этим занялись, начали делать это еще на этапе второго-третьего года работы компании, потому что поняли, что если мы сейчас всю эту кучу информации не начнем собирать в одном месте, то в последующем, когда организация начнет расти, скорость ее работы из-за этого может очень сильно уменьшиться.
То есть внедрять бизнес-процессы нужно, чем раньше, тем лучше. И если ты этого не сделаешь сейчас, то завтра будет только больнее, но боль от внедрения бизнес-процессов всегда меньше, чем боль от того, что они не были внедрены.
Придумано давно
С заказчиками - управленцами среднего и высшего звена компаний – мы, как подрядчики, в лице руководителей компании общаемся в основном исключительно на языке бизнес-процессов. То есть, когда возникают какие-то трудности в совместной работе, мы видим, как на каком-то моменте появляется проблема, и разговариваем не о конкретной ситуации, например, о том, что какой-то специалист не смог что-то качественно сделать, а на уровне сбоя в бизнес-процессе. В результате вместе берем и переделываем - бизнес-процесс взаимодействия наших организаций в рамках какой то операции.
Всегда нужно понимать, что если у тебя кто-то в организации «косячит», значит, ты неправильно сделал бизнес-процессы, либо ты не можешь их контролировать, либо у тебя просто нет инструментов для нормального выстраивания организационной структуры. И твои бизнес-процессы - просто листочки, висящие на стене, а на самом деле, люди работают, как хотят.
В действительности все это придумано уже очень давно, и по большому счету нет в этом какого-то ноу-хау. Взять советские предприятия с их технологическими картами или государственные структуры с разработанными различными министерствами должностными инструкциями, - все это то же самое. И если сегодня вы пишете шариковой ручкой, а лет 200 назад кто-то пользовался пером, то по факту вы делаете одно и то же, просто другим инструментом.
Регламент для летящего предпринимателя
По себе знаю, что современные информационные системы снижают нагрузку руководителя в плане оперативного управления, которое всегда занимает много времени.
Кроме того, не возникает потребность в «тушении пожаров»: если вы нормально ухаживаете за автомобилем (утром заправить, вечером помыть, раз в полгода загнать на станцию), то он не будет вас подводить. А если ничего из этого не делать, да еще ездить по кочкам, то, скорее всего, машина быстро сломается, а если мы на ней, скажем, возим хлеб, то когда-то настанет день, и кому-то хлеб не привезут: автомобиль сломался, потому что мы не выполняли регламенты.
Так внедрение бизнес-процессов (соответствующих регламентов, должностных инструкций и пр.) значительно упрощает жизнь предпринимателя, насколько бы летящим и воздушным (на идеях, амбициях) он ни был.
Да, для многих история с бизнес-процессами скучна и неинтересна, но по моему глубоко убеждению это одна из важных компетенций, которые нужно в себе развивать, внедрять в привычку, которая, как известно, формируется за 21 день.
По себе знаю, как тяжело дается систематизация, но я себе безумно благодарен за то, что когда-то буквально заставил всему этому научиться.
Я по-прежнему остался «летящим» предпринимателем, но при этом почувствовал, как под ногами появилась твердая почва.
Фото из архива Антона Фомичева