Сначала — моя история
Несколько лет я, как и многие из вас, работал программистом 1С на фиксе в одной из компаний. До этого я пробовал разные специальности – 4 года во франче работал программистом, руководителем проектов, умел закрывать по 200 часов, одновременно получая процент с проекта, за руководство и немного занимаясь продажами. Пробовал самостоятельно разрабатывать продукты, был начальником IT-отдела в большой компании, численностью 6 тысяч человек, примерял разные варианты применения нашей профессии – программиста 1С. Но все это позиции были несколько тупиковые, в первую очередь по доходу. Все мы получаем примерно одни и те же деньги, работаем в одних и тех же условиях.
Мне стало интересно, как можно зарабатывать больше денег, не занимаясь продажами и не создавая свой собственный бизнес. Я решил найти нишу в компании, в которой работал. Она должна была быть какой-нибудь особенной, никем не занятой. И хотелось, чтобы компания сама захотела платить деньги человеку в этой нише, чтобы не надо было никого обманывать или что-то накручивать. Чтобы это было объективно: человеку на этой позиции надо платить много денег.
Поиски были недолгими. В компании, где я работал, была совершенно не занята ниша, которую можно условно назвать наведение порядка в бизнес-процессах. В каждой компании есть куча проблем. Всегда что-то не работает, и нет человека, который придет и исправит бизнес-процесс. Я решил попробовать себя в роли специалиста, который может помочь собственнику решить его проблемы в бизнес-процессах.
На тот момент я работал в компании полгода и получал среднюю зарплату по рынку. Терять мне было нечего, тем более, что такую же работу я вполне мог найти в течение одной недели. В общем, я рассудил, что ничего страшного не произойдет, если вдруг ничего не получится и меня уволят.
Я пришел к собственнику и предложил ему улучшить самый проблемный процесс, который был в его бизнесе. На тот момент это был складской учет. Сейчас и мне, и тем, кто работает в этой компании, об этом даже стыдно вспоминать, но инвентаризации, которые проводились ежеквартально, показывали расхождения между учетной системой и фактическими остатками в десятки процентов. И по стоимости, и по количеству, и по количеству позиций. Это была беда. Компания реально имела правильные остатки в учетной системе только четыре раза в год – на следующий день после инвентаризации. Этот процесс я и стал приводить в порядок.
Мы договорились с собственником, что я должен снизить отклонения по результатам инвентаризации вдвое. Причем, ему терять особо было нечего, потому что до меня попытки все исправить уже предпринимали разные работники, и в целом задача считалась практически нерешаемой. Все это сильно подогревало мой интерес, потому что если все получится, то я автоматически становлюсь человеком, который умеет наводить порядок и решать нерешаемые задачи.
Итак, передо мной стояла задача в течение года снизить отклонения по результатам инвентаризации в 2 раза. На тот момент я не представлял, как этого добиться, но понимал, что складской учет – это вещь простая, поэтому все равно удастся что-нибудь сделать. Тем более, что снизить отклонения с десятков процентов до одного десятка процентов – это, вроде, не так сложно. Все, кто работал в сфере консультирования или подобной деятельности, понимают, что большинство проблем процесса устраняются достаточно простыми действиями.
С января по май я готовился, немного автоматизировал процессы, переписал бизнес-процесс складского учета, поменял потоки работы кладовщиков, бухгалтеров и вообще всю систему переделал, никому ничего не показывая и не рассказывая. В мае я раздал всем новые инструкции, и после первой в году инвентаризации началась новая жизнь – работа по моим правилам. Чтобы наблюдать результат, в дальнейшем мы проводили инвентаризации чаще – раз в два месяца. Уже первые результаты были положительными, а до конца года отклонения по результатам ревизии упали до долей 1%.
Успех был колоссальный, но в его устойчивость не верилось. Не верилось, что он сохранится, если я его оставлю. Тем не менее, результат был, и я получил все,о чем договаривался с собственником. Сейчас, по прошествии нескольких лет, устойчивость результата подтвердилась — 5 лет отклонения держатся в пределах 1 %..
Тогда я решил повторить эксперимент и предложил собственнику усовершенствовать другой проблемный процесс – процесс снабжения: там были дефициты, не позволявшие отгружать такие объемы, которые хотели наши клиенты. Договорились, что за год дефициты снизятся вдвое, а я еще выполню 10-15 проектов, связанных с 1С, — по автоматизации разных бизнес-процессов.
Во второй год опять все успешно удалось завершить, дефициты снизились более, чем в 2 раза, все IT-проекты были завершены успешно.
Поскольку зарплата полностью удовлетворяла все мои запросы на 1-2 года, я решил немного остепениться, успокоиться и посидеть на уютном теплом месте, которое я себе создал. Что оно собой представляло? Формально я был IT-директором, но кем я на самом деле был, понять сложно. Ведь чем занимается IT-директор? Как правило, он администрирует IT-инфраструктуры, руководит сисадминами, внедряет ERP-систему, участвует в совещаниях на совете директоров. Одной из моих ключевых обязанностей участие в процессах изменений, и по большей части — генерация, инициирование этих процессов, поиск и предложение решений, применение новых методик управления, экспертиза предлагаемых изменений, анализ эффективности других функций и подразделений, и, наконец — непосредственное участие в стратегическом развитии предприятия, вплоть до самостоятельной разработки стратегического плана всей компании. Таким образом, реализовалась та самая концепция самого ценного сотрудника — я им стал..
В этот момент мне стало интересно: почему у меня получилось, а у других не получилось? Собственник тоже подталкивал меня: говорил, что хочет, чтобы у других тоже получалось наводить порядок, потому что менеджеров много, они, как правило, занимаются оперативным управлением и стратегическим планированием, но практически никто не занимается системными изменениями своих процессом. В их должностную инструкцию, может, и записано, что они должны ускорять свой процесс, повышать его эффективность, но по факту этим никто не занимается. Почему так? Мне тоже стало интересно почему, и я пошел со всеми с ними разговаривать.
Я пришел к одному заместителю директора, и предложил внедрить контрольные карты Шухарта, чтобы у нас качество было лучше японского. Но оказалось, что коллега не знает, что такое контрольные карты Шухарта, что такое статистическое управление процессами, и только краем уха слышал про применение цикла Деминга в управлении качеством. Ладно…Пошел я к другому заместителю директора, и предложил внедрить контроллинг. Но и здесь не нашел поддержки. Еще чуть позже я узнал про баундри менеджмент (boundary management, управление границами) и всем заместителям директора предложил внедрить его системную часть, чтобы улучшить наши процессы. Но сколько я не разговаривал, никто особо не хотел вникать, о чем речь. Может, им было неинтересно или слишком сложно. Но по факту никто не разобрался. В общем, я рассказал обо всём, что знал и применял в компании. Но, никто меня так и не понял. Им до сих пор непонятно, почему, например, все удалось исправить в складском учете, причем тут контроллинг и управление границами.
В последнюю очередь я дошел до своих программистов – в мой штат входило 3 человека. Я им рассказал про управление границами, про контроллинг, про менеджмент качества, про agile и scrum… И на удивление они все поняли и могли со мной поговорить. Они поняли, почему проекты по складу и по снабжению получились. И тут меня осенило: на самом деле мир спасут программисты. Причем, именно программисты 1С.
Программисты 1С – единственные, кто смогут нормально, с нужной детальностью разобраться в бизнес-процессах
Почему именно они? На самом деле однозначного ответа я не знаю. У меня есть только тезисные намеки. Во-первых, они знают предметные области бизнеса, причем, знают их лучше всех остальных в компании. В своей жизни я встречал всего трех директоров – один финансовый, и два генеральных, которые знали лучше программистов, что происходит в компании на всех уровнях.
Кроме того, программисты 1С реально понимают, что такое алгоритм процесса. Это важно потому, что бизнес-процессы – это алгоритмы, и элементы в них могут быть банально не согласованы. Например, у нас в процессе по снабжению, над которым я работал, первый шаг – это составление годового плана закупок, а второй – ежедневная закупка. Эти шаги соединены прямой связью, то есть предполагается, что по этому алгоритму люди должны работать – составлять годовой план закупок и тут же исполнять заявку. Годовой план закупок составляется раз в год, а заявка поступает по 50 раз на день. На этом алгоритм заканчивается, и по нему надо работать. На самом деле для программистов знание алгоритмов – это конкурентное преимущество, потому что любой другой человек, не знакомый с ними, просто не понимает, как бизнес-процесс должен работать, и как это можно изобразить.
Еще один плюс программистов – у них достаточно свободного времени. Мы все понимаем, как программист может тратить на задачу в три раза дольше времени, чем на самом деле она требует, и мало кто это заметит. Это, опять же, конкурентное преимущество, потому что для того, чтобы приводить какой-то бизнес процесс в порядок, нужно иметь достаточно свободного времени на то, чтобы думать, наблюдать, изучать и пробовать. Большинство менеджеров этого свободного времени не имеют и гордятся этим. Хотя фактически это означает, что человек не может стать эффективным, потому что у него нет времени на повышение эффективности — замкнутый круг. В нашей культуре модно быть занятым, поэтому все остается на месте. А для нас, программистов, это преимущество. Мы можем найти свободное время и обо всем подумать.
Программисты могут быстро поменять систему. Это не на всех предприятиях применимо, но везде, где я работал, можно было вносить любые доработки, которые заблагорассудится. Особенно, если они не касаются ничьей работы. Например, я мог запустить систему, которая будет тайно измерять действия пользователей, и использовать затем эту информацию. Например, для анализа эффективности работы бухгалтерии и отслеживания стоимости ведения учета.
И последнее – программисты имеют доступ к большому количеству информации, именно административный доступ к системе. Поэтому они могут пользоваться ею в своем анализе. Никто другой таким ресурсом не обладает.
Рекомендации тем, кто захочет попробовать заняться наведением порядка в бизнес-процессах
Чтобы заниматься такой работой, во-первых, нужно иметь определенный уровень «отмороженности» – надо не бояться потерять работу, не бояться рискнуть, не бояться конфликтов с коллегами. У меня получалось это легко, потому что я работал всего полгода, я не успел ни с кем вступить в контакт, да и не собирался это делать. Я понимал, что люди приходят и уходят, а для меня важны мои результаты и их оценка собственником бизнеса. Плохо или хорошо ко мне относятся коллеги, меня это мало волновало в то время.
Второй момент – чтобы эффективно заниматься этой работой, к сожалению, придется учиться. Но учиться не на MBA, не на курсах, ни в институтах, а учиться самостоятельно. Например, я в первом проекте действовал интуитивно, я ничего не знал, только что такое управление качеством. Когда я начал читать литературу, какие методы повышения эффективности существуют, то обнаружил те технологии, которые применял. Я интуитивно это делал, а оказывается, это не моя придумка, все уже было написано. Но я потратил время и намного больше, чем если бы я сразу прочитал эту книгу. Здесь важно понимать, что когда изучаешь конкретную методику, ни одна из них, даже самая продвинутая, полностью не решит все проблемы бизнес-процесса.
Вторая фишка в том, что чем больше методик вы знаете, тем лучше. Например, в древней Японии жил Миямото Мусаси – один из самых известных фехтовальщиков, автор стиля двух мечей. Он учился в какой-то школе у какого-то мастера, потом путешествовал по Японии, сражался с разными мастерами. Если кто-то был сильнее его, он какое-то время у него учился. В результате он за несколько лет приобретал навыки различных практик разных мастеров и сформировал свою собственную школу, добавляя что-то свое. В итоге у него получилось уникальное мастерство. Здесь то же самое.
Можно, конечно, действовать как бизнес-консультанты. Они отличные ребята, мне очень помогали в свое время, мы обогащали своим опытом друг друга. Но они, как правило, приходят, чтобы внедрить какую-то методику, и внедряют не ту методику, которая нужна бизнесу. У нас тоже были такие грустные ситуации: никто не знает, как решить проблему и никто не хочет думать, как ее решить. Начинаем искать либо в интернете, либо звать консультанта, и спрашиваем у него, что нам может помочь. Консультант думает и говорит, что надо теорию ограничений внедрить. Платим ему за рекомендацию, тратимся на внедрение, но результата ноль.
Почему так получается? Потому что консультант сказал, внедряем такую-то систему, и все согласились с ним. Прекрасно, но одна методика не закрывает всех проблем даже одного бизнес-процесса, особенно если не совпадают исходные предпосылки — наши и те, что требуются для внедрения методики.
В практике, которую я рекомендую, надо брать лучшее и внедрять лучшее. Не брать методы целиком, а брать их ключевые особенности, фишки, практики. И самое важное – надо понимать суть. Возьмем, к примеру, скрам (scrum) или аджайл. Мне кажется, что не все их до конца понимают. Я тоже читал книгу Джеффа Сазерленда, которая некоторым кажется «легким чтивом». Мне она показалась глубоким чтивом, потому что одна из основополагающих основ скрама – это управление качеством, и про это там написано. Там написано про Toyota Production, про то, как Джефф Сазерленд показывал скрам в Японии, насколько он там прижился и было близок их философии. И Сазерленд рассказывал про важность роли скрам-мастера, про цикл Деминга. Роль скрам-мастера – это постоянное ускорение процесса. Все остальное, что есть в скраме, – поэтапная сдача, удовлетворение заказчика, четкий перечень работ на период спринта — тоже важно, но это все должно двигаться все быстрее и быстрее. Скорость работы должна все время возрастать в тех единицах, в которых она измеряется.
Возможно, здесь дело в переводе, потому что у нас книгу перевели как «Скрам – революционный метод управления проектами», а если дословно английское название переводить, то получится: «Скрам – в два раза больше за вдвое меньший срок», то есть даже в названии идет отсылка к скорости, как ключевой функции скрама.
Когда я внедрял скрам, за первый месяц скорость увеличилась вдвое без каких-то особых изменений. Мы нашли изменения, мы модифицировали скрам под себя, чтобы он работал намного быстрее. Единственное, как в интернете пишут, — перед нами стал вопрос: «Мы увеличили скорость вдвое, осталось понять, что же мы делаем с такой скоростью?». Впрочем, это уже совсем другая область…
Методики решения бизнес-проблем
Я выбрал несколько методик, которые лично рекомендую.
1. Баундри менеджмент (управление границами).
Преподают его в «Сколково», других книг и материалов нет. Мне посчастливилось присутствовать на лекции профессора из Гарварда, который проповедует баундри менеджмент, а также я прочитал несколько статей в Harvard Business Review про работы Эрика Триста. Баундри менеджмент говорит о том, что надо уметь видеть границы и работать с границами. Границ полно, они повсюду — между отделами, между разными видами работ, между функциями, между оперативной и аналитической работой. Знание баундри менеджмента не открывает каких-то высших истин, но позволяет видеть реальность в несколько ином свете — через призму границ. И, соответственно, управлять ими — возводить там, где это необходимо, и убирать там, где они мешают.
2. Контроллинг (управление на основе цифр).
Контроллинг, если кратко — это управление на основе цифр. Здесь важна каждая часть определения — и "управление", и "на основе", и "цифр".
У нас, в России, плохо со всеми тремя составляющими контроллинга. Особенно если учесть, что они тесно взаимосвязаны как друг с другом, так и с другими частями бизнес-системы.
Первое, что плохо — цифры. Их мало и они низкого качества. Про требования к цифрам хорошо написано, например, в википедии, повторять не буду.
Значительную часть цифр мы берем из информационных систем — например, из 1С. Так вот, качество цифр в 1С, как правило, никуда не годится. Как минимум, из-за возможности изменять данные задним числом.
Понятно, что вины разработчиков 1С в этом нет — они лишь учитывают требования рынка и менталитета отечественного учета. Но для целей контроллинга принципы работы 1С с данными лучше изменить, на конкретном предприятии. Тем более, что это несложно.
Дальше цифры из 1С, как правило, проходят полуручную обработку, с использованием Excel, например. Качества данным, равно как и оперативности, такая обработка тоже не добавляет.
В конце концов, итоговый отчет еще кто-то перепроверяет, чтобы случайно не подать руководителю цифры с ошибками.
В итоге, цифры попадают к адресату красивыми, проверенными, но очень поздно. Обычно — после окончания периода (месяца, недели, и т.д.).
И тут все очень просто. Если цифры о январе вам попали в феврале, то деятельностью января вы уже управлять не можете. Потому что январь уже кончился ).
А если ваши цифры основаны на бух.учете, и вы не крупный налогоплательщик, то не исключаю, что относительно адекватные цифры вы получаете раз в квартал.
Дальше понятно. Получаете цифры раз в месяц — у вас есть возможность управлять по цифрам (т.е. осуществлять контроллинг) 12 раз в год. Практикуете квартальную отчетность — управляете 4 раза в год. Плюс бонус — годовая отчетность.
Остальное время управление, как правило, выполняется вслепую.
Когда (и если) цифры все-таки появляются, то вступает в действие вторая проблема — как управлять на основе цифр?
Если таких цифр у руководителя раньше не было, то их появление вызовет вау-эффект. Он будет смотреть и крутить цифры и так и эдак, вызывать людей на ковер, требовать объяснений и расследований. Поигравшись с цифрами, проведя разборы, грозно пообещав всем сотрудникам, что "уж теперь-то я с вас не слезу", руководитель очень быстро успокоится и бросит это дело. Инструментом пользоваться перестанет. А проблемы функции останутся на месте.
Так происходит из-за недостаточных компетенций руководителя в контроллинге, в первую очередь. Он просто не знает, что делать с этими цифрами. Что сделать — знает, что делать — нет. Сделать — это то, о чем написано выше (поругаться, поиграться). Делать — это ежедневный бизнес-процесс.
Подбираемся все ближе к сути. Все очень просто: цифра должна стать частью бизнес-процесса. В бизнес-процессе должно быть четко понятно, кто, что, и когда должен делать при отклонении цифры от нормы (любые варианты — выше границы, ниже границы, выход за коридор, наличие тренда, невыполнение квантиля и т.д.)
И вот она ключевая дилемма: цифра есть, она должна стать частью бизнес-системы, чтобы повысить эффективность управления, но… этого не происходит. Почему?
Потому что российский руководитель не отдаст конкуренту кусок своей власти.
Конкуренты российского руководителя — качественный и работающий бизнес-процесс, продуманная взаимовыгодная мотивация и правильная автоматизация — увы, оставят руководителя без работы. А тут еще плоские структуры на подходе.
Контроллинг я особенно рекомендую, и особенно — программистам 1С. Это голубой океан повышения эффективности управления в России.
3. Скрам
Обязательно прочитайте и попробуйте на практике скрам. Если вы читали, но не пробовали — считайте, что не знаете. Читать лучше книгу, например Сазерленда, а не статьи в интернете.
Скрам познается только практикой, и с обязательными измерениями объемов выполненной работы. Лично попробуйте две важнейшие роли — владельца продукта и скрам-мастера.
Особенно важно прочувствовать на практике роль скрам-мастера, когда вы сможете увеличить объем закрываемых за спринт задач, не увеличивая ресурсы и стоимость спринта.
4. ТОС (теория ограничений систем)
Базовые, фундаментальные принципы повышения эффективности, которые можно применить практически в любой области, в любом бизнес-процессе и бизнес-системе в целом.
Если не знакомы, то не буду лишать удовольствия от прочтения книг Элияху Голдратта. Рекомендация аналогичная скраму — прочитайте и попробуйте. На какой бы должности вы не находились, какую бы работу не выполняли, там найдется место для повышения эффективности методами ТОС.
5. Миксуйте принципы, для создания прикладных решений в конкретной ситуации
Это главная рекомендация, ключ к успеху. Поймите принципы, суть, и создавайте уникальные прикладные решения — бизнес-процессы и бизнес-системы.
Вот что сказал на эту тему Элияху Голдратт в статье "Стоя на плечах гигантов":
"Есть разница между прикладными решениями (применениями) и фундаментальными концепциями, на которых основаны эти решения. Концепции являются общими, прикладные решения — это адаптация концепций к конкретной среде. Как мы уже видели, подобная адаптация не является простой и делает необходимой разработку определенных элементов решения. Мы должны помнить — прикладное решение основано на исходных посылках (иногда — скрытых) о конкретной среде. Не надо ожидать, что это прикладное решение будет работать в среде, для которой исходные посылки не верны".
Не правда ли, похоже на кастомизацию типового решения 1С под конкретное предприятие, т.е. под среду? А мы с вами не этим разве каждый день занимаемся?
Осталось лишь расширить свой пакет инструментов — влиять не только на информационную систему, но и на окружающую ее среду.
P.S.
Тема программирования и отладки бизнеса продолжается, обогащается новыми знаниями и практическим опытом.
Пока в виде блогов, но это только начало:
http://biz-programming.livejournal.com/
http://business-programming.blogspot.ru
***************
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 DEVELOPER. Больше статей можно прочитать здесь.
В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.
Related Posts
Оценка и планирование проекта
Мысли о видах информационных систем…
Конфигурация "Выдача пропусков и учет рабочего времени"
Управление ИТ-проектами. Модуль 3: продвинутый курс по гибкому управлению проектами. Agile. Первый поток. Вебинары проходят с 11 сентября по 27 ноября 2024 г.
Загрузка/Выгрузка Excel для справочника "Графики работы сотрудников"
Онлайн-курсы по управлению ИТ-проектами от Марии Темчиной
А где — же Винни?
Вы не думали, что только это могло стать причиной улучшения учета?
Это сработает, если директора и руководители отделов апатичны или чем-то заняты. На деле иногда у собственника по несколько в день «ходоков» с рацпредложениями. Т.е. деятельный начальник склада предложил бы, к примеру, внедрить WMS или приблизить процесс реализации к складским отгрузкам, чтобы уменьшить разницу между реальными остатками и «в программе», финдиректор сделал бы свою модель бюджетирования, с блэк-джеком и прочим, и пришел к собственнику за ресурсами на реализацию и т.д.. Т.е. ниша знатока бизнес-процессов часто плотно засижена разными руководителями и именно программисту 1С там особо нечего делать.
Автор так тебе подняли зарплату в 5 раз или ты просто стал «Самым ценным сотрудником по своему мнению» ?
(5) Стать самым ценным намного важнее, чем зарплата))) При таком подходе зарплата — не цель, а естественное следствие, о котором даже и упоминать не стоит)))
Да у автора ЧСВ можно как эталон использовать
(6) так статья начинается с того что выше среднего уровня доходов не подняться.
В итоге не понятно поднялся, или только уровень ошибок в инвентаризации сократил.
Отлично написано. Хочу также.
Стать самым ценным — это чушь.
В действительности самый ценный сотрудник начинает контролировать бизнес, поэтому от него стараются избавиться. Так что не сношайте себе мозг, увольтесь сами, это сэкономит время и здоровье
За статью лайк конечно, чем то напомнило меня. Только я так и не решился встать на тот путь по которому пошел автор.
«…И тут меня осенило: на самом деле мир спасут программисты. Причем, именно программисты 1С….» Полна страна героями)
Автор, спасибо за статью. Можете написать рекомендуемый Вами перечень литературы для прочтения?
Не понимаю почему так много критики. Человек проявил инициативу, вышел за границы конфигуратора, добился успеха и поделился своим опытом. Автору успехов в последующих проектах. Спасибо за статью.
Спасибо за статью, мне было очень интересно читать, единственное возник вопрос.
Как я понял у вас уже есть многолетний опыт разработки и вы уже пошли намного дальше, а что вы можете посоветовать тем кто только начал изучать 1с? книги, видео, семинары, статьи? Мне лично трудно систематизировать свое обучение в этом направление может вы подскажете заранее спасибо.
А еще бывает — сидит пахарь средней руки и пашет, заявки идут конвейером, он закрывает одну за другой и доволен.
Руководство смотрит — крутой прогер, а не повысить его нам, скажем, до руководителя проектов.
Повышает.
Пахарь выныривает из конфигуратора,
Обнаруживает, что вокруг есть еще люди, которыми, оказывается, надо руководить, вместо ТЗ читать мысли заказчика до появления такового и т.д.
Пык, мык, бестолково проходит время, накапливается негатив, в прогеры обратно возвращаться уже не комильфо.
Уходит в другую контору.
Опять пашет, пока не «повысили».
И т.д.
(14)
Экскурсия по аду. Видят, в двух котлах варятся грешники. Около одного котла — ватага чертей с вилами, а около другого — никого.
— Почему вы все у одного котла?
— Да тут евреи варятся. Стоит на секунду отойти, как они все собираются, подсаживают друг друга, один вылезет — других вытаскивает. Если их не сторожить — все разбегутся!
— А почему тогда второй котел не охраняете?
— Там варятся русские. Отличные ребята! Если один пробует удрать, другие его назад тащат:
«Ты чё, лучше других быть хочешь?! »
(17)
Есть такие компании, которые вот это доверят 1С-нику, пусть даже и в статусе ИТ-директора?
И его сразу же не сожрали другие руководители?
Это в Челябинске такое комфортное болото во всём?
Бывает что просто власти не хватает, ты знаешь как делать, пытаешься через своего руководителя продвинуть оптимизацию процесса, где необходимо давление на другие подразделения, а Он не заинтересован в их продвижении да и портить отношения с руководителем другого подразделения не хочет, его и так все устраивает(и подвинуть его не подвинешь так как он уже …. лет сидит на этом месте, и зарекомендовал себя как стабильный сидок). И вот ты делаешь одну попытку, вторую, третью … и все в пустую. Периодически твои идеи удается продвинуть и реализовать что подогревает желание действовать дальше. А иногда твою идею сначала сливают как не рентабельную и через некоторое время выдвигают как свою ((((.
Хорошая статья. Человек продемонстрировал, как программист 1С может стать «больше чем программистом» и реально помочь бизнесу. Особенная благодарность за методики и перечень литературы.
Нельзя решить организационные проблемы техническими средствами, если автор считает по другому, то он глубоко ошибается. И поэтому программисты и ИТ-директора мир не спасут…
(21) Думаю автор имел вииду, що понимание процессов програмных и реальных здорово помагает продвинуться по службе
(22)
Куда автор продвинулся-то?
Сидит на партнерском форуме и также как и раньше потроха КА, УПП и ERP обсуждает.
(23) я должен, видимо, в антикафе потягивать смузи, вейпить и обсуждаждать фьючерсы и опционы?
(22) Если люди, ответственные за эти процессы по своим должностным обязанностям, мышей не ловят, то да, наверное можно и продвинутся. Но профессиональный программист по определению не может знать о логистике больше профессионального логиста, например.
Роль бизнес-аналитикаменеджера по развитию — логичное продолжение для многих специалистов по 1С. Непонятно, почему автор, не смотря на уже 5 летний опыт в этой роли, все еще считает ее ключевой для бизнеса. Пора уже двигаться дальше в своем развитии)
«Знать задачи — дело подчиненных, дело правителя — знать людей». Весь бизнес строится на взаимоотношениях. И ключевая задача руководителей — строить эффективные отношения. И навыки развивать в этом направлении.
Например, многие опытные предприниматели придерживаются позиции, прямо противоположной автору — и считают большое количество цифр вредным для топ-менеджмента (см. например книги Боба Файфера, Харви Маккея).
Да, все перечисленное в статье влияет на отношения (скрам — в особенности), но …все это не приоритетно. И далеко не всегда полезно для бизнеса и его владельцев (к сожалению — так как я тоже люблю внедрять всякие такие штуки).
(15) Александр, да пребудет с вами Гилев, Чистов и Радченко с Хрусталевой 🙂 Аминь!
Я тут все думал, что мне не нравится в этой статье ) И вот какой момент: в заголовке написано «как повысить свой доход в разы..» и предлагается взяться за проекты оптимизации бизнес-процессов. Статья адресована программистам 1С. Но если посмотреть на вакансии на hh.ru то для бизнес-аналитика средняя зп ~ 90 000 руб. А средняя зп хорошего программиста 1С ~ 160 000 руб.
То есть, если руководитель адекватный, по идее, он должен увидеть понижение ценности и не согласует подобные «отвлечения». И уж тем более не станет доплачивать еще сверху.
Я бы назвал стратегию этой статьи удачным вариантом «выхода из профессии» для тех специалистов 1С, которые хотят перестать быть айтишниками.
PS По моему опыту, чтобы аналитику платили over 160 000, у него должен быть многолетний опыт выполнения бизнес-проектов из той сферы, за реализацию которых он просит денег.
Абсолютно согласен с автором. Статья глубокая, выстраданная. Я бы даже сказал универсальная. Подходы, высказанные в этой статье могут быть применены в различных областях. Не обращая внимание на критику (относительно зарплаты, ценных сотрудников и т.п.) СТАТЬЯ ПОКАЗЫВАЕТ СИСТЕМНЫЙ ПОДХОД К РЕШЕНИЮ ПРОБЛЕМЫ. Кто не увидел, тому не покажешь. Сильно и здорово. Молодец.
Статья хорошая. Но мне кажется, что автор путает теплое с мягким и/или претендует на роль гуру в этом вопросе.
Начинание хорошее, тут однозначно плюс.. И блог почитаю какое то время.
Но нужно понимать существенную разницу.
А именно, есть программисты, у которых отлично получается программировать (кодить), а есть администраторы, руководители и т.д.
Одним по кайфу кодить и видеть результат в виде работающей и используемой, приносящей пользу разработки.
Другим по кайфу админить, менять процессу, улучшать, использовать методики управления и повышения качества и проч.
Так вот, автор из вторых, когда он был программистом, то был просто не на своем месте и ему пятки жгло это свое место занять. интуитивно, понятное дело. Вот и пошел изучать да процессы менять, потому что его прет от таких результатов его работы.
НО.
Будоражить умы программистов, которые из первых, это пытаться сподвигнуть их заниматься не своим делом, встреть неудачу на этом пути и разочароваться в профессии. Не делай так, автор.
Стать крутым кодером и в разы повысить свой доход тоже можно, но в 1С, к сожалению это единицы, а все остальные зарабатывают «примерно одни деньги».
Так вот, те программисты, которым по душе менять процессы и руководить/админить/управлять могут спрыгнуть и поднять доход как автор, Остальных денежная замануха только собъет с пути и все.
(28)
То, что это средняя зп программиста 1С, по мне так сильно сказано, такой уровень зп предлагает небольшой процент компаний (смотрел на том же hh примерно год назад) и часто требуют не только навыки программирования, но и умение быть консультантом/аналитиком/руководителем.
Статья хорошая, но не лишена пафоса. Отсылки даются к хорошим методам, конечно. Особенно — скрам, аджайл, границы и прочее. Но написано из какой-то детской позиции. Как сказал один герой Марка Твена из рассказа о сигнализации против воров: «.».
Человек перерос из программиста в бизнес аналитика, вот и все. На сайте есть не менее удачные истории, с большим количеством деталей. Просто не все кто думают что-то делают, а он сделал. На вашем месте я бы ушел вообще в консалтинг и работал на себя.
Тут у автора конечно звезды совпали.
— директор доверил программисту поменять учет не только на складе, но и в бухгалтерии
— директор справедливо поднял з/п за успех
— директор помог продавить пользователей под изменения, которым они всегда сопротивляются
— не было других «решал», которые продавливали бы альтернативные решения проблемы и всё путали
Но молодец, спасибо за статью и рад что у вас получилось.
Почему именно они? На самом деле однозначного ответа я не знаю. У меня есть только тезисные намеки. Во-первых, они знают предметные области бизнеса, причем, знают их лучше всех остальных в компании. В своей жизни я встречал всего трех директоров – один финансовый, и два генеральных, которые знали лучше программистов, что происходит в компании на всех уровнях.
Тот момент, когда осознал себя аналитиком, а не программистом )) Ну не встречаются программисты 1С с директорами )) И уж точно можно сказать с точностью до наоборот — как только ты можешь разобраться в бизнесс-процессе на уровне Ивана Белокаменцева, то ты уже не просто программист 1С )
ЗЫ. Спасибо за обработку по структуре затрат с партнерского форума.
(36)
еще как встречаются. Причем на регулярной основе в виде отдельной планерки.
Прочитал, человек в своей нынешней деятельности напомнил меня, с одной лишь разницей, стартовые точки разные. Он шел от программиста, а я от продажника. А на вопрос многих специалистов «А зачем ты сюда заходишь?», я отвечу за знаниями. Кто что нового интересного полезного для управление придумал. И если говорить честно, то в лучшем случаи 1% обработак интересен с точки срезения управления. Бизнес-Аналитик знающий 1С — это СУПЕР. Уважуха. С удовольствием зайду на блоги и почитаю
(33) Я может как то не так читаю, но все таки не аналитег, а ИТ-директро вроде…Да и в общем функционал скорее руководительский описан…
1) Директор не просто доверил, а программист его убедил,
2) Про повышение зп ничего не могу сказать, свечку не держал),
3)Программист в данном случае САМ продавливал пользователей,
4)Другие «Решала» однозначно были, было множество конфликтных ситуаций и «Стрелок».
Просто «совпали звезды» — точно не про эту историю!
Я видел историю изнутри, поэтому и высказал «пару строк».
(40) Звезды совпали в том, что на предприятии был бардак, и ТС смог убедить в этом директора 🙂 Если такого бардака нет, никто не будет слушать непрофессионала, лезущего в профессиональные вопросы.
(1) хм, и правда. Надо поправить.
(2) нет, разумеется. Такой опыт (более частые инвентаризации) предпринимался и ранее, но успеха не имел.
Тут было комплексное решение по исправлению ситуации, а инвентаризации — лишь способ измерения.
Ну и в целом это плохой путь — вести учет с помощью инвентаризаций и ревизий. Один знакомый главбух, например, считает периодическое формирование актов сверок — главным залогом правильных взаиморасчетов.
(5) все как написано в начале статьи — поднять доход в разы, занять другую должность, стать самым ценным сотрудником (по мнению тех, кто выше).
Правда, это уже пройденный этап.
(6) вы правы насчет зарплаты. Скорее даже не следствие, а способ измерения, одна из координат. Что-то вроде спортивного результата.
(7) хорошо бы, если бы это было так. Но перед глазами масса людей, у которых стоит поучиться ЧСВ.
(8) да да, поднялся. Уровень ошибок в учете, а не в инвентаризации. Почти до нуля.
(9) спасибо, уверен, у вас получится. Никаких препятствий нет.
(10) уволился за день до того, как вы написали пост.
Но контролировать все и вся не было моей целью никогда. Дать другим инструмент контроля — да, если им это нужно. Но мало кто умеет пользоваться — эта братия, менеджерская, так себе.
(11) никогда не поздно, я думаю. Лишь бы вам это интересно было.
Мало кому этот путь по-настоящему интересен.
Так же, как и путь настоящего программиста 1С.
(12) увы или ура, но это так.
И этому я нашел объяснение, в том числе, среди других подмножеств программистов — например тех, кто на java script программирует. Толковые люди рассказали, чем опыт в 1С лучше применительно к бизнес-программированию.
(13) Владимир, приветствую.
Я рекомендую, в первую очередь, базовую, фундаментальную литературу. Она помогает понять принципы, чтобы потом находить им прикладное применение.
Также полезны книги типа биликов (сборников изречений или коротких заметок на определенные темы).
Например:
1. «Цель», «Выбор» (Голдратт);
2. «Scrum. Революционный метод управления проектами» (Сазерленд)
3. «Русская модель управления» (Прохоров)
4. «Хагакурэ (кодекс самурая)» (Ямамото Цунэтомо)
5. «Rework. Бизнес без предрассудков» (Джейсон Фрайд)
6. «Искусство системного мышления» (Айан Макдермотт)
7. «7 навыков высокоэффективных людей» (Стивен Кови)
и т.д.
(14) спасибо, и вам успехов!
(15) лично я прочитал одну книгу по 1С в жизни — Радченко, на первой неделе работы.
Семинары не посещал, видео не смотрел, ИТС пользовался раз 5 в жизни.
Не берусь утверждать, что мой опыт будет вам полезен.
По своему опыту скажу, что наиболее интенсивно опыт растет, когда ты остаешься один в решении реальных задач по 1С. Например, когда ты единственный программист 1С в компании, и помочь тебе никто не может.
В этом случае приходится разбираться во многом, и разбираться быстро. Это такое, контекстное обучение, когда не изучаешь академические курсы «про все на свете», а решаешь конкретную задачу и читаешь соответствующую информацию.
Второй совет, который я бы мог дать — нужен разнообразный опыт. Надо поработать и во франче, и на фиксе. На фиксе нужно поработать обязательно, т.к. франч практически никогда не дает нужной глубины понимания бизнеса, и нужной глубины ответственности за свои решения.
(16) да, вы очень точно описали принцип Паркера.
Такое случается на каждом шагу, в каждой специальности.
Если речь о росте от специалиста до руководителя, то надо понять главное: руководить — это просто такая работа. Которую надо научиться делать.
Также, как и лидерство. Ничего сверхъестественного нет ни в том, ни в другом.
(17) ну или так:
После корабле крушения на необитаемы остров попали русский, немец и китаец.
Собрались с мыслями сидят думаю что делать , подумали-подумали и решили сделать удочку и рыбы наловить!
Сделали, забросили в море и поймали золотую рыбку… Та говорит:
Рыбка-Мужики каждому по одному желанию, все больше не могу…
Китаец- меня домой!!!! (сказано сделано!)
Немец- (Подумал и решил что это я с пустыми руками останусь!) Мне чемодан денег и домой!!!(сказано сделано!)
Русский-(Почесал затылок…) мне ящик водки и этих двоих обратно…
(18) в Челябинске, как и везде, чистое поле. А в чистом поле — маленькое болото, в котором сидят по уши куча толковых людей, смотрят вниз, и не замечают, что вокруг — чистое поле.
Другие руководители — те же люди, которые когда-то тоже были кем-то. Продавцами, инженерами, конструкторами, снабженцами, экономистами, бухгалтерами, кладовщиками и т.д.
Нет ни одного человека, который бы с начала карьеры имел специальность и компетенции «стратегического развития предприятий». Просто потому, что такая работа еще более неопределенная, чем «автоматизация предприятий».
Для одних предприятий правильная стратегия — расширение производства, для других — улучшение дистрибуции, для третьих — расширение штата отдела, ограничивающего цепочку создания ценности, для четвертого — расширение рынка сбыта, для пятого — ускорение потока генерации денег через линейку продуктов и т.д.
Также, как и автоматизация. Есть неправильная — «автоматизировать надо всё», а есть правильная — автоматизировать то, что нужно.
Главное — увидеть то, что нужно, т.е. ключевой элемент, узкое место на данный момент. Увидеть узкое место не может, как правило, ни один из руководителей, т.к. он видит лишь свою часть цепи. И обычно считает, что проблемы где-то в другом месте.
Чтобы увидеть нужное место — узкое — требуется смотреть со стороны и анализировать. Очень похоже на анализ производительности кода в 1С, только с учетом многопоточности жизни, бизнес-единиц, асинхронности бизнес-процессов и т.д.
Об этом, собственно, программирование и отладка бизнеса. Задача больше инженерная, чем менеджерская или, например, лидерская. Чтобы далеко не бегать за примерами, смотрите на Голдратта, которого называют бизнес-гуру или гением менеджмента, а пришел из физики.
Чем 1Сники хуже? Я вроде в статье упомянул, почему задача понимания, куда двигаться предприятию в стратегии, виднее программисту. Другие ребята (директора по финансам, логистике, производству, продажам и всему прочему) просто имеют намного более узкий кругозор, хоть и кажутся со стороны великими и всемогущими, особенно если на MBA учились.
(19) как говорили великие, власть нельзя дать, ее можно только взять.
Тут нужен комплекс мер, зависящий от контекста.
Например, если кто-то выдает ваши идеи за свои, нужно стараться сделать так, чтобы идея имела авторство, которое запомнится максимальному числу нужных людей. У нас это был общедоступный банк идей, с указанием авторства, даты публикации, отметки выполнения и т.д. Важно успеть идею застолбить.
Если проблема в том, что кто-то не хочет раскачивать лодку, то лично я сам ее раскачивал, намеренно. Для этого (как упомянуто в статье) нужна изначальная отмороженность — т.е. отсутствие цели выстраивать отношения с коллегами.
Ну и т.д. Можно какое-то время быть «как все», хорошим парнем, переть по карьерной лестнице, чтобы получить власть.
Главное — не унывать и помнить, что всегда можно что-то изменить. Разумеется, трезво оценивая, насколько это затратно и долго, и готовы ли вы делать такие инвестиции времени.
(20) спасибо. Надеюсь, статья принесет вам пользу — это ее цель.
(21) неисповедимы пути Господни. Рядом сидит программист, который техническими средствами увеличил объем производства одного завода в 4 раза.
Ну и в статье речь не о технических средствах. Теория ограничений — техническое средство? Scrum — техническое средство?
(22) да, в том числе. От цели зависит.
Если цель — продвинуться по службе, или увеличить свой доход — да, понимание реальных процессов и умение с ними обращаться поможет.
Интереснее другое — работа на нескольких уровнях одновременно.
Один уровень — автоматизация бизнес-процесса, который кто-то придумал.
Другой уровень — самому придумать бизнес-процесс, и автоматизировать его.
Третий уровень — выбрать, какой бизнес-процесс реально нужно придумывать или оптимизировать, потом придумать и автоматизировать.
Ну и т.д. Это — реально интересно.
(23) ура, не зря мне ставили диагноз «анатидаефобия».
(25) совершенно верно. Но где взять профессионального логиста? Кто он такой? Как понять, профессиональный он или нет?
Обычно ответ простой — справляется или нет со своими обязанностями, с поставленными задачами.
Но тут система с обратной связью — обязанности и постановка задач тоже зависит от компетенций человека. Требования и цели снижаются вышестоящими, чтобы не раскачивать лодку. Если вышестоящий в такой же системе ценностей, то он со временем тоже начинает считать логиста профессиональным.
И все развитие той же службы логистики сводится к тому, чтобы обеспечивать приемлемый уровень выполнения обязанностей. Иногда автоматизироваться, например.
А как же развитие? А никак, потому что задачи такой нет. Хотя логист продолжает выглядеть профессионально.
(26) мой опыт и наблюдения говорят, что нет приоритетного и главного. Есть конкретная задача, есть подходящие и неподходящие для нее методы.
Взять ту же задачу про склад, которая упомянута в статье. Успех был ровно потому, что перестали пытаться решить ее на уровне отношений, а заменили системой, которой безразличны люди внутри. К чему это привело, помимо решения задачи? Как раз появились отношения, основанные на общем успехе.
Про цифры — согласен с вами. Но контроллинг к внедрению в России настоятельно рекомендую. Ровно для того, чтобы убедить топ-менеджмент на практике — цифры им не нужны.
(28) речь не идет о профессии бизнес-аналитик, скорее бизнес-консультант. Доходы бизнес-консультантов обладают большооооооооооооооой дисперсией.
Но термин «бизнес-консультант» мне самому не нравится. Больше подходит какая-то аналогия с growth hacker, но я не смог найти подходящего названия.
И вакансий таких нет (я не нашел, по крайней мере). Соответственно, и зарплаты не ясны.
(29) спасибо. Успехов вам!
(30) Смысл — не в замене специальности, а в объединении специальностей с достижением синергетического эффекта.
А компетенции программиста 1С помогут лучше и быстрее понять то, что не понимают окружающие коллеги.
(31) да, я тоже часто стал встречать такие требования. Иногда в вакансиях стали открыто писать — мы не знаем, что делать, чтобы стать лучше, приди и скажи. На такой работе ТЗ не будет, и в окружающий мир вникать придется, на уровне бизнес-процессов, задач и целей.
(32)
Хорошо подходит цитата того же Марка Твена:
«Дети и дураки всегда говорят правду», — гласит старинная мудрость. Вывод ясен: взрослые и мудрые люди правду никогда не говорят.
(33) спасибо, успехов вам!
(63) По поводу профессионалов — так их сразу видно. Если специалист четко знает, что нужно для бизнеса, почему это нужно, и как этого достичь — это сразу понятно. Простой пример — у нас на складе внедрили WMS — систему. Внедренцы пугали, что по их опыту 20% персонала с системой работать не сможет, что в первые 3-4 месяца работы 20% ТСД побьют — так вот, ничего подобного не произошло за счет грамотной работы начальника склада. Никакой программист 1С даже близко рядом стоять не может.
(60) Ну он решил не организационную, а техническую проблему скорее всего. Под организационными я понимаю проблемы низкого уровня компетенции собственников, руководителей и исполнителей. Эти проблемы и призвана решить в частности ТОС. Но надо понимать, что в ТОС главное — это изменение парадигмы мышления, никакими техническими средствами этого не сделать. Если вы смогли убедить свое руководство в необходимости смены пардигмы мышления — то, что вы при этом являлись программистом 1С — это случайность. Просто в вашей компании не нашлось никого другого, кто в этом был бы заинтересован.
(35) детали немного не такие.
Решалы были, они пробовали до меня, их было несколько. С более широкими полномочиями.
Продавливанием он не занимался, пришлось все самому, в основном, делать.
(36) встречаются или нет — зависит, скорее, от самих программистов. От того, ищут они этой встречи или нет.
(39) в широком понимании ит-директорства — да, это оно и есть. Если понимать функцию ит-директора как реинжиниринг бизнес-процессов.
Но обычно ит-директоры другим занимаются. 1С, например, внедряют.
(40) Игорян, привет. Удачи вам там.
(41) бардак есть везде. От системы координат зависит, считать это бардаком или нет.
Вот анекдот на тему:
После шторма мужик попал на необитаемый остров. Воды нет – одни камни и колючки. И прожил он там целый год. Его заметили с проходящего судна и спасли. Как оказалось, мужик на острове неплохо сохранился, его и спрашивают:
– Где пищу-то здесь доставал?
Мужик показывает корешки, колючки всякие, дает попробовать… Пробуют…
– Какая гадость!
– Я привык, мне нравится…
– Ну а воду? Воду-то где брал?
Он показывает, как выпаривал из рубашки, собирая по каплям. Дает попробовать… Пробуют…
– Фу! Какая гадость!
– Я привык, мне нравится.
– Ну, а без женщин-то как смог прожить?
Мужик достает фотографию:
– Вот…
– Так это же Ломоносов!!!
– Я привык, мне нравится…
А непрофессионала будут слушать и профессионалы, просто не с кондачка. Если правильно выстроить цепочку событий, то будут.
(71) есть понимание, чем WMS-система помогла бизнесу?
(72) в развитии вообще мало кто заинтересован по-настоящему, тут дело не в конкретной компании.
Смена парадигмы мышления — это здорово, но это редко срабатывает, т.к. долго и рискованно. В компании был, например, специальный человек, который год ходил и пытался поменять парадигму мышления всей компании. Выглядело это весело, но толку в итоге было ровно ноль.
Иногда лучше внедрить конкретное техническое, или организационно-техническое решение, основанное на правильной концепции, но никому не говорить о концепции. А когда заработает, объяснить, в чем была фишка. Я так стал делать в последнее время.
Проект по складу, например, содержал в себе несколько фундаментальных концепций, но при внедрении никто об этом не знал, не приходилось менять ничью парадигму, тратя на это драгоценное время. Но в итоге все получилось, и фундаментальные концепции нашли свое применение в реальности. Например, получился self-management (более подробно — ).
(78) Если коротко, без WMS не было бы одного из направлений бизнеса. Ну и снижение потерь и увеличение надежности работы склада конечно.
(79) Подробности ничего не прояснили если честно, мне, как человеку тесно связанному со складской логистикой, интересно всеже как конкретно работает self-management на складе.
Не в обиду вам сказано, но мне кажется, что описанная вами частная ситуация невоспроизводима, кроме как с вами и с вашим предприятием…
(80) вполне воспроизводима, если такой целью задаться.
Не как коробочное решение, а как подход — взять фундаментальную основу и применить к конкретной ситуации. Ну и как цель — можно добиться той же цели, взяв за основу ту же платформу и изготовив на ее основе решение для конкретной ситуации.
Ошибка большинства (я не про вас) в том, что они ищут коробочных решений.
Я был на семинаре Дага Киркпатрика, одного из идеологов self-management, и явно это видел, среди других присутствующих. Почти никому не интересна философия и принципы, только алгоритмы, кейсы и практики.
Повторю цитату Голдратта из статьи, она вроде к месту будет:
Есть разница между прикладными решениями (применениями) и фундаментальными концепциями, на которых основаны эти решения. Концепции являются общими, прикладные решения — это адаптация концепций к конкретной среде. Как мы уже видели, подобная адаптация не является простой и делает необходимой разработку определенных элементов решения. Мы должны помнить — прикладное решение основано на исходных посылках (иногда — скрытых) о конкретной среде. Не надо ожидать, что это прикладное решение будет работать в среде, для которой исходные посылки не верны.
Решил еще раз попробовать поучаствовать в конференции инфостарта, вдруг смогу быть кому-то полезен. На этот раз по более прикладной теме, но тоже из области менеджмента.
Если еще не надоел, и есть желание пообщаться, то вот ссылка на доклад —
(75) Основная функция ИТ-директора — формирование ИТ-инфраструктуры, т.е. сделать так, чтобы ИТ решения максимально закрыли потребности бизнеса. Внедрение 1С или реинжениринг БП — это всего лишь инструменты… В какой момент брать лопату а в какой молоток — решение самостоятельное….
(83)+1. интересно.
(85) совершенно верно, но обычно все не так происходит.
Типовой ИТ-директор предлагает инструменты, и придумывает для них задачи. И задачи переформулируются соответствующим образом — «внедрить инструмент». А изначальная задача по дороге теряется.
Бывает так. Ставят ИТ-директору задачу: «сделай так, чтобы без потерь сократить бухгалтерию вдвое».
Он говорит — ок, надо подумать. Подумал и говорит — надо внедрить 1С.
Вроде все понятно: вот задача, вот решение.
Дальше идет подмена одного другим. Задача перестает фигурировать в изначальной постановке. Появляется новая задача — внедрить 1С. Она решается, под нее пишется проектная документация. Критерии успешности проекта формулируются соответствущим образом, типа «все сроки проекта соблюдены, в бюджет уложились, качество принято внутренними заказчиками».
Потом, возможно, случайно кто-нибудь вспомнит, что хотели бухгалтерию сократить. А она за время проекта выросла в 1.5 раза. Но что уж теперь поделать.
Дальше работает обратная связь — просто перестают ставить правильные задачи, тоже начинают разговаривать на языке применения инструментов. Типа «нам нужен сайт», «нам нужно облако», «нам нужна pdm» и т.д.
Неплохо об этом написано здесь —
(87) главный герой статьи — реально крутой (кто бы что не говорил…) :).
Зафиксировать и выполнить конечную цель, найти свою ценность для бизнеса и максимально ее использовать -это реальный признак руководителя нового типа, управления ценностями. Думаю следующий шаг логически- это собственный бизнес в области консалтинга…
(88) спасибо, но речь не обо мне, а обо всех нас.
Лично я следующим шагом выбрал расширение кругозора в смежных темах, не связанных с менеджментом. Менеджмент, увы, поднадоел.
Только недавно был в ситуации, аналогичной описанной автором в начале, но был «сбит на взлете».
Толкнули генеральному директору идею о создании отдела бизнес- процессов, наметили план работ.
Столкнулись с некомпетентностью некоторых представителей топ- менеджмента (и своей тоже, естественно), их страхами:
1) генеральный увидит, что они некомпетентны, будет ругаться;
2) потерять власть из- за наличия порядка в компании, ибо сейчас каждая дирекция в компании- маленькое королевство, где правит топ. И топ раз в месяц производит генеральному отчет по форме «Все хорошо, прекрасная маркиза».
Как следствие- столкнулись с противодействием на всех уровнях работы с процессами, например:
1) на стадии разработки:
Отказ делать хоть что- то для развития процесса- «вы отдел бизнес- процессов, это же вам надо»
Заведомо неверное описание работы процессов «как есть» и «как будет»
Постоянное дополнение различными хотелками, с блокированием работы по нему если хотелки не будут учтены:
«А давайте в этот процесс еще и %облегчение работы своей дирекции/ перекладывание ответственности/…%впишем»
«То, что вы хотите вписать не из этой оперы, это не относится к нашему процессу, оно даже в его границы(заранее прописанные и согласованные) не попадает»
«Тогда я не согласую процесс, мы по нему не будем работать»
2) на стадии внедрения- мы разработали регламенты(инструкции, процедуры, стандарты и т.д. )-внедрять мы их должны, естественно (в виде очного обучения/ предоставления инструкций/ тестов/ обучающих видео), но по ним все равно никто не работает, т.к. люди склонны работать не «как надо» а «как удобно»
Забегая вперед, закономерный итог: через полгода отдел разогнан по причине «нет результатов работы»
3) на стадии контроля процесса:
При защите KPI:
а) он посчитан неверно
б) (когда доказали, что посчитан верно)- он разработан неверно
в) (когда припомнили, что разработка велась «вместе», KPI согласованы подписями)- общие слова + сейчас уже невозможно понять, что конкретно повлияло на значение KPI
При автоматизации- отсутствие работы в автоматизированном контуре в принципе. Т.е. работают как раньше работали.
Ответственности с себя не снимаю, понимаю, что отсутствие результата- следствие моих:
1) Компетентности,
2) Личностных качеств,
3) Профессиональных привычек.
Знающим- вопросы:
1) Что мы сделали не так?
2) Что и как бы вы сделали в такой ситуации?
(90) Тут все просто, у вас не было административного ресурса для разгребания бардака. Поэтому шансов, кроме как выходить на собственников, и убеждать их в необходимости изменений, изначально не было…
(69)
«Дети и дураки всегда говорят правду», — гласит старинная мудрость. Вывод ясен: взрослые и мудрые люди правду никогда не говорят.
У Марка Твена не очень хорошо с формальной логикой 😉 Из этого максимум что следует: дети и дураки неправду никогда не говорят.
(117) вообще то из утверждения Твена следует что «взросные люди и не дураки не всегда говорят правду»
(117)
Как вариант имеется ввиду что дети и дураки верят в то что говорят.
(43) Если проблема уменьшается при помощи инвентаризаций — это или плохая система учета, или плохие складские работники. Поэтому проблема решается увольнением: или бухгалтера, который разработал такую систему учета, которой нельзя до конца верить, или кладовщика, который плохо исполняет свою работу
(127) проблема не уменьшается при помощи инвентаризации, а только измеряется. Хотя, в эксперименте с котом Шредингера, вроде, инвентаризация помогает )
(16) В точку. Все было именно так X лет назад ). Надо отказываться и брать деньгами. Каждому своё.
(15) начни с человеческого ника и аватара — будь человеком, остальное наверстаешь
(35) зачем вы мусолите звезды, ищите причины успеха?
успех внутри человека. если у вас сейчас не получается, то у других получилось не из-за звезд
да, и вообще, тема-то статьи не про успех
это кейс. как относиться к кейсам — изучать, изучать, еще раз изучать — и однажды, сделав что-то подобное , вы не вспомните , что это из кейса, но вы подумаете: «какой же молодец — все сам придумал»
В Челябинске экология. по возможности валят оттуда, оставшиеся вне конкуренции.