Pull to refresh

Comments 5

Спасибо за глубокий подход к нетривиальному вопросу. Ибо очень напрягает подход, отличный от подхода Jive.

Вся беда (имхо) в том, что рассмотрение выручка/затраты требует не ИТ-ишных весьма навыков, которыми CEO по-хорошему владеть должен. Как и ITSM-подходами, сквозь призму которых, сам по себе портал — никому не нужная ерундовина, а интерес представляют именно те сервисы, которые он предоставляет, и для которых реально подсчитать отдачу. Убеждения CEO, как это принято иногда, «мягкими формулировками» о «повышении эффективности» и прочие слова по древу, очень раздражают. У любого бизнес-решения может быть только одно обоснование — экономическое (риск входит в экономический анализ, так что экстремумы по типу «потеряем бизнес» — это тоже экономическое обоснование).

Вдобавок, любители посчитать ROI тоже неправы (считать-то NPV надо), они хоть и связаны, но так непросто, что уж лучше даже не вдаваться.
Андрей,
спасибо за комментарий. Я и сам был бы рад перевести все в выручку, но не знаю как перевести в выручку будущие возможные инновации (а это одно из решений, поддерживаемых корпоративными соцсетями)?
Вспоминаю историю от Ицхака Адизеса, что фраза в гостиничном номере «оставьте полотенце на вешалке, если не хотите чтобы его стирали» сэкономила миллиарды долларов в гостиничной индустрии. Придумала это никому неизвестная горничная, получающая 25 долларов в неделю. Просто ей дали возможность внести свое предложение. Ну вот как такое оценить?
Лично я бы не стал относить инновации к заслугам портала, у скольких компаний я видел порталы, а инноваций и видно не было (думаю горничная Адизеса вряд ли писала на корпоративном портале). Хотя возможность внести и не потерять предложение ценна.

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

Можно оценивать так: 100 рацпредложений в год, из которых реализовали 5, каждое из 5 привело к снижению брака в среднем на 2%, в сумме 10%. Числа можно брать из статистики по отрасли, по предприятию, и вполне даже оценивать исходя из правила больших чисел (среднее по пространству равно среднему по времени) — то есть взять за короткий промежуток времени количество тех же предложений в каком-нибудь одном подразделении (выбрать какое-нибудь усредненное) и умножить на их количество и на период. Затраты со стороны ИТ на внедрение и поддержку такого решения в большинстве случаев смешные (хоть бесплатный шарепойнт ставь).

Я исхожу из того, что даже грубая прикидка на числах лучше качественной формулировки. Потому что это некоторая модель системы, есть конечно мягкие модели (как Арнольд в качестве примера пишет, «чем дальше в лес, тем больше дров»), но преимущество жесткой модели что её численный результат дает путь к оптимизациям. Пусть например мы получили, что 10% снижения брака не дадут нам рентабельности для решения по корпоративным коммуникациям, значит есть выходы — снижать стоимость решения, повышать его эффективность (регламентированием использования либо еще как-то, кастомизацией например, интеграцией).
Я даже немного не прав, с утра не проснулся. Оценивать эффективность следует в ситуациях «с проектом» и «без проекта». То есть эффект от решения по корпоративным коммуникациям — те предложения, которые не потерялись (а не все, которые и так бы были рассмотрены).

Я не говорю, что эффект этот маленький, равно как и не говорю, что большой. В какой-то компании эффект может быть ощутимым, а в какой-то овчинка может и не стоить выделки.
Согласен что надо пытаться сделать количественную оценку. Но чтобы не было совсем уж притянуто за уши.
Sign up to leave a comment.