пятница, 28 июля 2017 г.

Смотреть на себя его глазами...

Социальная перцепция это процесс восприятия "социальных объектов": других людей, социальных групп, социальных общностей.

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

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

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

«Идентификация» обозначает отождествление себя с другим, выражает установленный эмпирический факт, что одним из самых простых способов понимания другого человека является уподобление себя ему.

Рефлексия (отличается от философского определения рефлексии) - осознание себя в восприятии другого: что я думаю о том, что он или она думает обо мне.

Интерпретация поведения другого человека может основываться на знании причин этого поведения. Нужно помнить, что люди, как правило, не знают действительных причин поведения не только других людей, но и самих себя. Более того, люди начинают приписывать друг другу причины поведения, образцы поведения и прочие характеристики. Приписывание проводится, например, на основе сходства поведения воспринимаемого лица с каким-либо другим "образцом", имевшем место в прошлом, либо, например, на основе "применения" собственного поведения и мотивов в аналогичной ситуации.
Способов приписывания "хватает" на целую систему приписывания (атрибуции).
Чем развитие и разнообразнее психика, тем шире и пространнее система атрибуции.

Среди частностей можно выделить общие черты в систем атрибуции (приписывании) с позиции (и в предположении) изучения «рядового человека», который пытается понять причину и следствие тех событий, свидетелем или участником которых он является.

Г. Келли. Три типа атрибуции:
  • личностная атрибуция: причина приписывается лично совершающему поступок; 
  • объектная атрибуция: причина приписывается тому объекту, на который направлено действие;
  • обстоятельственная атрибуция: причина совершающегося приписывается обстоятельствам.
Было выявлено, что наблюдатель событий чаще использует личностную атрибуцию, а участник событий склонен в большей мере объяснить происходящее обстоятельствами.
Поэтому обычно при приписывании причин успеха и неудачи: участник действия «винит» в неудаче преимущественно обстоятельства, а наблюдатель «винит» в неудаче, прежде всего, самого исполнителя.

Также для оценки ситуации межличностного восприятия стоит учитывать влияние эффектов, возникающих при восприятии людьми друг друга:

  • эффект ореола («галоэффект»), 
  • эффект новизны и первичности, 
  • эффект, или явление, стереотипизации.

«Эффект ореола» проявляется при формировании первого впечатления о человеке в том, что общее благоприятное впечатление приводит к позитивным оценкам и неизвестных качеств воспринимаемого и, наоборот, общее неблагоприятное впечатление способствует преобладанию негативных оценок.
Эффекты «первичности» и «новизны» касаются значимости определенного порядка предъявления информации о человеке для составления представления о нем.

* * *

МЕЖДУ СТИМУЛОМ И РЕАКЦИЕЙ СУЩЕСТВУЕТ СВОБОДА ВЫБОРА.

Именно свобода выбора делает человека уникальным существом во вселенной. Помимо СПОСОБНОСТИ К САМОАНАЛИЗУ, мы наделены ВООБРАЖЕНИЕМ — способностью творить за пределами объективной реальности. А также НРАВСТВЕННЫМ ЧУВСТВОМ, или СОВЕСТЬЮ — глубоко укоренившимися представлениями о том, что хорошо, а что плохо; способностью распознавать законы, управляющие нашим поведением; чувством меры, позволяющим нам жить по этим законам. И наконец, мы обладаем НЕЗАВИСИМОЙ ВОЛЕЙ – способностью действовать, как подсказывают самосознание и совесть — независимо от внешних факторов.

Даже самые умные животные не обладают этими свойствами.

7 навыков лидера. Стивен Кови

воскресенье, 23 июля 2017 г.

Иногда можно и отказаться от ERP-проекта

Технологии имеют "символическое" свойства: автомобиль часто воспринимается скорее как показатель статуса, а не средство передвижения.

Откуда мы знаем характеристики технологий?
Очевидно. что
- мы знаем "их авторитетных источников"
- мы изучаем характеристики артефактов, тестируем их
- мы знаем их на основе дедукции: выводим из научных теорий или моделей

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

"Вы, очевидно, думаете, что вещи существуют только для того, чтобы их кто-то мог понять. Но так ли это на самом деле? Какая разница событиям, поймет их кто-нибудь или нет?"
Роберт Шекли. "Майрикс".



* * *

4 причины отказать от ERP-проекта.
  1. Ваши бизнес-процессы являются реальным источником в аших проблем. Новая ERP-система хотя и поможет что-то улучшить, но эта будет плохой инвестицией по сравнению с банальным реинжинирингом бизнес-процессов.
  2. Ваша организационная система является источником проблем. ERP-система здесь ничем не поможет. До ERP-системы необходимо определить или улучшить организационные роли, распределение ответственности и организационную структуру.
  3. У вас есть убежденность, что лучшим выбором является монолитная (зачастую, в рекламных целях утверждается - интегрированная) ERP-система. На рынке уже присутствует достаточное число альтернатив монолитным решениям.
  4. При выборе решения стоит встать на позицию технологического агностицизма. То есть по возможности ориентироваться на стратегию и бизнес-цели, а не технологию их достижения с тем, чтобы избежать выбора - "пусть сначала стреляет, а целится будем потом".
Вольный пересказ заметки Four Reasons to Ditch Your ERP Project

* * *

Если же решили перейти к цифровой трансформации, то будет полезно узнать о ловушках на этом пути согласно The Do It Yourself Digital Transformation Project: Beware of These Ten Pitfalls.


1 и 2. Фокусирование только на какой одной ERP. Неполный охват предлагаемых рынков вариантов.

3. Считать, что ценовое предложение поставщика решения таковым и останется по ходу исполнения проекта. Не только потому, что поставщику нужно продавать, но и потому, что поставщик не может знать всех обстоятельств вашего бизнеса.
4. Пытаться достичь амбиционных целей проекта и заниматься минимизацией затрат.
5. Думать, что новая программа улучшить ваши бизнес-процессы. Современные системы настолько гибкие, что могут реализовать ваши далекие от совершенства бизнес-процессы.
6. Игнорировать методы управления организационными изменениями. Даже если все готовы к изменениям, действия не следуют автоматически из готовности действовать.
7 и 8. Опирайтесь на сильную команду, а не на "звездных людей" в деле внедрения систем. Не пытайте сами принимать все решения, пусть ваша команда участвует в принятии ключевых решений.

9. Избегание или отсутствие навыков в привлечении независимых консультантов или в использование агностических технологий. (прим. технологий, механизмы работы которых полностью не понятны).
10. Делать ставку в своей карьеры на единственном этом проекте.


* * *

Десять вопросов перед началом цифровой трансформации


Десять вопросов, правильные ответы на которые помогут Вам убедиться в правильном выборе и направления реализации проектов цифровой трансформации.
1. Какова и есть стратегия самого бизнеса? Ваш проект должен решать задачи именно такой стратегии и если ее нет, то... дальше наверное бесполезно задавать вопросы... 
2. Как ваша ИТ стратегия будет поддерживать бизнес-стратегию?
3. Ваша организация готова к переменам? Ответ должен формулироваться в соответствии с методиками управления организационными изменениями.
4. Какие бизнес-процессы формируют конкурентные преимущества ваше организации? Если конкурентных преимуществ нет, то можно попробовать оперировать желаемыми и достижимыми конкурентными преимуществами.
5. Готовы ли вы изменять ваши бизнес-процессы и как далеко простирается ваша готовность?
6. Какой масштаб кастомизации и доработок вы готовы терпеть?
7. Вы собираетесь внедрять одну интегрированную ERP или внедрять набор лучших решений в соответствующих функциональных областях.
8. Кто будет в вашей команде и какова она - ваша команда? 
9. Есть у вас мысли об организации коммуникаций и даже, более того, стратегия коммуникаций по ходу выполнения проекта.
10. Какова будет стратегия управления проектами?

* * *

Пятиэтапное руководство по спасению проектов цифровой трансформации или внедрению ERP

Шаги, которые можно предприятий, если проект начал выполняться совсем не так, как ожидалось.

1. Оцените ущерб.
2. Приостановите проект и сосредоточьтесь на людях и процессах. Тщательное определение бизнес-процессов и преодоление сопротивления организационным изменениям дают экспоненциальную отдачу.
3. Рассмотрите альтернативы. Проектым командам кажется, что у них единственный путь, единственный способ тех или иных технологических решений. Это далеко не так. Как минимум, план Б всегда есть, и помимо этого, еще много жизнеспособных альтернатив. Их просто нужно увидеть.
4. Если вы нашли альтернативы в предыдущем пункте, рассмотрите компромиссы наименьшего риска и наименьших затрат.
5. Прекратите проект, если у вас нет приемлемых решений, нет хватает ресурсов, бюджета, поддержки руководства, команды, спосоров, нет других критических факторов успеха.

среда, 19 июля 2017 г.

Решето для отсеивания негодных проектов

План — это шантаж глупцов непредвиденными обстоятельствами. 
Ворота для лошадей, которых нет. 
План основывается на известной тебе информации, 
а известная тебе информация всегда устаревшая.
М.Флинн. Танцор Января.

Алексеем Жуковым (выходные данные статьи приведены внизу) приведена в разделе "Итоги" схема с описанием видов неудовлетворительных результатов проектов.
Схема примечательная и является собой неплохой "маяк" для оценки инвестпроектов.

А именно, проверьте проекта на наличие:

  • Кассовых разрывов.
  • Плохого коэффициента покрытия долга.
  • Срока окупаемости (есть нет его - вообще плохо).
  • Отрицательной приведенной стоимости проекта (NPV<0).
  • Плохой внутренней ставки доходности (IRR< ставки дисконтирования).





Корпоративный менеджмент, http://www.cfin.ru

Адрес документа: http://www.cfin.ru/finanalysis/math/reading.shtml
Обновлено: 13.04.2016







Основные проблемы при моделировании инвестиционного проекта

Жуков Алексей консультант по экономике ГК Альт-Инвест

вторник, 11 июля 2017 г.

Практики организации разработки ПО мирового класса

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

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

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

Кое-что из статьи "Руководство для разработчиков программного обеспечения", опубликованной МакКинзи.
An executive’s guide to software development

15 практик, которые позволять определить организацию разработчиков мирового класса.


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

  • Структура решений, которые управляют стратегическими решениями.
    • Миграция решений в облако
    • Выбор платформы, определяющийся четырьмя ключевыми факторами:
      • коммерческие факторы, в главном это расходы на платформу;
      • простота использования, включая быстрый доступ и возможности управления платформой;
      • особенности платформы: архитектура платформы, сложность данных, гибкость обеспечения согласованности;
      • суверенитет данных: размещение данных в местах, разрешенных законами соответствующего государства.
    • Микросервисы, контейнерная архитектура
  • Практика управления программным решением включая концептуализацию и дизайн программного решения.
    • Высокое качество управления разработкой программного решения.
    • Ориентированный на пользователя дизайн программного решения.
  • Практика разработки продукта.
    • DevOps (акроним от англ. development и operations) — набор практик, нацеленных на активное взаимодействие и интеграцию специалистов по разработке и специалистов по информационно-технологическому обслуживанию. Базируется на идее о тесной взаимозависимости разработки и эксплуатации программного обеспечения, и нацелен на то, чтобы помогать организациям быстрее создавать и обновлять программные продукты и сервисы. Непрерывная разработка, непрерывная интеграция.
    • Автоматизация тестирования и разработки тестов.
    • Архитектура на основе использования интерфейсов прикладного программирования (API).
    • Производительность и качество.
  • Доступность элементов планирования и исполнения операций. Организациям требуется набор определенных функций и практик, которые не относятся к техническим вопросам создания ПО, но необходимы для создания эффективного программного обеспечения.
  • Портфолио-менеджмент и управление расходами и доходами на создание ПО.
  • Управление талантами.
  • Управление безопасностью и управление рисками.
Дело в том, что C-уровень (управляющие директора)e должен играть более активную роль в разработке программного обеспечения и делать соответствующие инвестиции в создание практик разработки программного обеспечения мирового уровня в своей организации.