понедельник, 16 октября 2017 г.

Возвращение к себе

Рассмотрим ситуацию Вы и правильные вещи. Правильные причины.

Если рассмотреть действия, правильные вещи и правильные причины, можно получить следующие экзистенциональные ситуации, которые семантически можно охарактеризировать (то есть - означить), следующим образом.

1. Делаем правильные вещи по неправильным причинам. Что делать? Разбираться с причинами.

2. Делаем неправильные вещи по правильным причинам. Что делать? Разбираться с неправильными вещами.

И наконец

3. Делаем правильные вещи по правильным причинам.

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

* * *

Простая очевидность. Три результата, два источника. Но очень сложная в реализации. Может потому, что очевидность.
В самом деле, Ницше: «Что требует самых основательных, самых упорных доказательств, так это очевидность. Ибо слишком многим недостает глаз, чтобы видеть ее».

четверг, 12 октября 2017 г.

Парадоксы бухгалтерского учета

1. Прибыль есть, денег нет.
Парадокс возможен, если предприятие деньги, полученные в виде прибыли, вложило в немонетарные активы, дебиторскую задолженность или прибегло к капитализации текущих расходов.
Варианты.
a)             Куплены ценности, стоимость которых выше прибыли.
b)             Продан товар, а деньги не получены.
c)              Увеличены остатки незавершенного производства, тем сам увеличена прибыль за счет меньшей себестоимости готовой продукции.
d)             Текущие расходы отнесены к расходам прошлых периодов.
2. Деньги есть, прибыли нет.
Варианты.
a)             Продан товар за деньги ниже себестоимости.
b)             Получен кредит, займ, аванс, предоплату, платежи в счет доходов будущих периодов.
3. Имущественная масса (актив) изменилась, а прибыль нет.
Варианты.
a)             Получены ценности, но не оплачены. Актив уравновешен пассивом.
b)             Приняты (изъяты) ценности в порядке целевого финансирования.
c)              Безвозмездно получены (переданы) ценности.
d)             Повышены (понижены) цены на товары.
e)              Проведена переоценка имущества.
f)              Установлены неучтенные излишки (недостача).
g)              Погашена кредиторская задолженность.
4. Прибыль изменилась, имущественная масса в активе – нет.
Ситуация возникает, если производится капитализация понесенных расходов и изменение структуры пассива. Парадокс возникает как следствие принципа идентификации. Два следствия. 1) выплачены расходы за несколько периодов вперед, однако появился счет расходы будущих периодов, который уравновесил отток денег. 2) Произведена реструктуризация задолженности и часть отнесена на финансовый результат.
5. Получен реальный убыток – в учете показана прибыль.
Возникает как результат капитализации расходов (деньги оплачены, но не отражены как расход) или в результате амортизации. Капитализация создает искусственную прибыль, не обеспеченную деньгами, амортизация уменьшает учетную прибыль, не затрагивая реальную.
6. Одна и та же сумма может выступать как доход, так и расход.
Следствие принципа самостоятельности. Две ситуации. 1) Дивиденды могут рассматриваться как часть прибыли или как расход. 2) Переплата лимита (нормируемых расходов). Один и тот же расход трактуется как расход предприятия, доход работника и т.д.
7. Один и тот же объект может быть отнесен как к основным, так и к оборотным средствам.
8. Учетный остаток не равен фактическому. Исключений практически не бывает.
9. Бухгалтерский учет нельзя понять из него самого.
10. Сумма средств предприятия не равна их совокупной стоимости.
11. Прибыль, исчисленная за все время существования фирмы (с момента основания до ликвидации), но не может быть равна сумме прибылей, исчисленных за каждый отчетный период.
Подлинная прибыль определяется как разность между полученным и вложенным капиталом. Исчислить истинную прибыль невозможно по причине изменения покупательной способности денег, переоценок, изменения норм и методов амортизации, изменения методологических принципов. Согласно принципу непрерывности общая прибыль вообще невозможна и поэтому прибыль за каждую отчетную дату конечна и не подлежит суммированию с прибылью за другие отчетные периоды.

12. Бухгалтерская отчетность отражает факты хозяйственной жизни, имевшие место в прошлом, но смысл отчетности состоит в том, чтобы дать возможность потенциальным пользователям принимать решения на будущее.

воскресенье, 8 октября 2017 г.

Типы компаний.

Слова Эйлера: «В мире не происходит ничего, в чем не был бы виден смысл какого-нибудь
максимума или минимума».
Карл Зигель - шутливое высказывание: «По Лейбницу наш мир является наилучшим из всех возможных миров, а поэтому законы можно описать экстремальными принципами».

Управлять можно ли? Или все получается исходя из экстремальных принципов?
А именно...


среда, 4 октября 2017 г.

К определению цифровой трасформации

Экипаж в такелаж привносил ералаш,
Паруса поднимались не к месту;
И маршрут был непрост, ибо курсом норд-ост
Отклоняло героев к норд-весту.


Льюис Кэрролл.


Графическое определение цифровой трансформации от SAP

Вот такая инфографика:


Перевод терминов.

Digital Transformation: Connecting People, Things, and Businesses
Цифровая трансформация: Связь-подключение Людей, Вещей и деловой среды.

Digitization: companies become a software-driven company by ...

Цифровизация: компании становятся программно управляемыми компаниями посредством ...
Разумного подключения Людей вещей и Бизнеса

Intelligently connecting People, Things and Businesses


  • Разумность (Intelligently) опосредуется машинным обучением (Machine Learning)
  • Подключение (Connecting) - технологиями интеграции (Integration) и оркестровки (гармоничным сочетанием механизмов управления, Orchestration).
  • Люди (People) опираются на сотрудничество (Collaboration), используют мобильные технологии (Mobile), свой пользовательский опыт (UX), аналитику в режиме реального времени (Real-time Analitics).
  • Вещи (Things) это - Интернет Вещей (IoT).
  • Бизнес (бизнес-объекты и/или бизнес-отношения, Businesses) - техногии интеграции (Integration), технологии на базе программных интерфейсов приложения (APIs), микросервисы  (представления сервис-ориентированной архитектуры, Microservices).

суббота, 30 сентября 2017 г.

12 факторная модель приложений

Оригинал модели содержится The Twelve-Factor App

Толкование и расширенные пояснения можно найти в книгах и на сайте Мартина Фаулера
Сайт Martin Fowler

В курсах OpenSAP имеется вот такой неплохой слайд с 12 факторами



Так как сайты могут "исчезать", изменяться, проходиться через этапы редизайна и порой не в лучшую стороны с исчезновением контента, ниже приводится копипаст 12 принципов на дату 30 сентября 2017 года (https://12factor.net/ru/)

Двенадцать факторов

I. Кодовая база

Одна кодовая база, отслеживаемая в системе контроля версий, – множество развёртываний

II. Зависимости

Явно объявляйте и изолируйте зависимости

III. Конфигурация

Сохраняйте конфигурацию в среде выполнения

IV. Сторонние службы (Backing Services)

Считайте сторонние службы (backing services) подключаемыми ресурсами

V. Сборка, релиз, выполнение

Строго разделяйте стадии сборки и выполнения

VI. Процессы

Запускайте приложение как один или несколько процессов не сохраняющих внутреннее состояние (stateless)

VII. Привязка портов (Port binding)

Экспортируйте сервисы через привязку портов

VIII. Параллелизм

Масштабируйте приложение с помощью процессов

IX. Утилизируемость (Disposability)

Максимизируйте надёжность с помощью быстрого запуска и корректного завершения работы

X. Паритет разработки/работы приложения

Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания (production) максимально похожими

XI. Журналирование (Logs)

Рассматривайте журнал как поток событий

XII. Задачи администрирования

Выполняйте задачи администрирования/управления с помощью разовых процессов


* * *


I. Кодовая база

Одна кодовая база, отслеживаемая в системе контроля версий, – множество развёртываний

Приложение двенадцати факторов всегда отслеживается в системе контроля версий, такой как Git, Mercurial или Subversion. Копия базы данных отслеживаемых версий называется репозиторием кода (code repository), что часто сокращается до code repo или просто до репозиторий (repo)
Кодовая база – это один репозиторий (в централизованных системах контроля версий, как Subversion) или множество репозиториев, имеющих общие начальные коммиты (в децентрализованных системах контроля версий, как Git).
Одна кодовая база  множество развёртываний
Всегда есть однозначное соответствие между кодовой базой и приложением:
  • Если есть несколько кодовых баз, то это не приложение — это распределённая система. Каждый компонент в распределённой системе является приложением и каждый компонент может индивидуально соответствовать двенадцати факторам.
  • Факт того, что несколько приложений совместно используют тот же самый код, является нарушением двенадцати факторов. Решением в данной ситуации является выделение общего кода в библиотеки, которые могут быть подключены через менеджер зависимостей.
Существует только одна кодовая база для каждого приложения, но может быть множество развёртываний одного и того же приложения. Развёрнутым приложением (deploy) является запущенный экземпляр приложения. Как правило, это рабочее развёртывание сайта и одно или несколько промежуточных развёртываний сайта. Кроме того каждый разработчик имеет копию приложения, запущенного в его локальном окружении разработки, каждая из которых также квалифицируется как развёрнутое приложение (deploy).
Кодовая база обязана быть единой для всех развёртываний, однако разные версии одной кодовой базы могут выполняться в каждом из развёртываний. Например разработчик может иметь некоторые изменения которые ещё не добавлены в промежуточное развёртывание; промежуточное развёртывание может иметь некоторые изменения, которые ещё не добавлены в рабочее развёртывание. Однако, все эти развёртывания используют одну и ту же кодовую базу, таким образом можно их идентифицировать как разные развёртывания одного и того же приложения.

II. Зависимости

Явно объявляйте и изолируйте зависимости

Большинство языков программирования поставляются вместе с менеджером пакетов для распространения библиотек, таким как CPAN в Perl или Rubygems в Ruby. Библиотеки, устанавливаемые менеджером пакетов, могут быть установлены доступными для всей системы (так называемые “системные пакеты”) или доступными только приложению в директорию содержащую приложение (так называемые “vendoring” и “bundling”).
Приложение двенадцати факторов никогда не зависит от неявно существующих, доступных всей системе пакетов. Приложение объявляет все свои зависимости полностью и точно с помощью манифеста декларации зависимостей. Кроме того, оно использует инструмент изоляции зависимостей во время выполнения для обеспечения того, что неявные зависимости не “просочились” из окружающей системы. Полная и явная спецификация зависимостей применяется равным образом как при разработке, так и при работе приложения.
Например, Bundler в Ruby использует Gemfile как формат манифеста для объявления зависимостей и bundle exec – для изоляции зависимостей. Python имеет два различных инструмента для этих задач: Pip используется для объявления и Virtualenv – для изоляции. Даже C имеет Autoconf для объявления зависимостей, и статическое связывание может обеспечить изоляцию зависимостей. Независимо от того, какой набор инструментов используется, объявление и изоляция зависимостей должны всегда использоваться совместно – только одного из них недостаточно, чтобы удовлетворить двенадцати факторам.
Одним из преимуществ явного объявления зависимостей является то, что это упрощает настройку приложения для новых разработчиков. Новый разработчик может скопировать кодовую базу приложения на свою машину, необходимыми требованиями для которой являются только наличие среды выполнения языка и менеджера пакетов. Всё необходимое для запуска кода приложения может быть настроено с помощью определённой команды настройки. Например, для Ruby/Bundler командой настройки является bundle install, для Clojure/Leiningen это lein deps.
Приложение двенадцати факторов также не полагается на неявное существование любых инструментов системы. Примером является запуск программ ImageMagick и curl. Хотя эти инструменты могут присутствовать во многих или даже в большинстве систем, нет никакой гарантии, что они будут присутствовать на всех системах, где приложение может работать в будущем, или будет ли версия найденная в другой системе совместима с приложением. Если приложению необходимо запустить инструмент системы, то этот инструмент должен быть включён в приложение.

III. Конфигурация

Сохраняйте конфигурацию в среде выполнения

Конфигурация приложения – это всё, что может меняться между развёртываниями (среда разработки, промежуточное и рабочее развёртывание). Это включает в себя:
  • Идентификаторы подключения к ресурсам типа базы данных, кэш-памяти и другим сторонним службам
  • Регистрационные данные для подключения к внешним сервисам, например, к Amazon S3 или Twitter
  • Значения зависимые от среды развёртывания такие, как каноническое имя хоста
Иногда приложения хранят конфигурации как константы в коде. Это нарушение методологии двенадцати факторов, которая требует строгого разделения конфигурации и кода. Конфигурация может существенно различаться между развёртываниями, код не должен различаться.
Лакмусовой бумажкой того, правильно ли разделены конфигурация и код приложения, является факт того, что кодовая база приложения может быть в любой момент открыта в свободный доступ без компрометации каких-либо приватных данных.
Обратите внимание, что это определение “конфигурации” не включает внутренние конфигурации приложения, например такие как ‘config/routes.rb’ в Rails, или того как основные модули будут связаны в Spring. Этот тип конфигурации не меняется между развёртываниями и поэтому лучше всего держать его в коде.
Другим подходом к конфигурации является использование конфигурационных файлов, которые не сохраняются в систему контроля версия, например ‘config/database.yml’ в Rails. Это огромное улучшение перед использованием констант, которые сохраняются в коде, но по-прежнему и у этого метода есть недостатки: легко по ошибке сохранить конфигурационный файл в репозиторий; существует тенденция когда конфигурационные файлы разбросаны в разных местах и в разных форматах, из за этого становится трудно просматривать и управлять всеми настройками в одном месте. Кроме того форматы этих файлов, как правило, специфичны для конкретного языка или фреймворка.
Приложение двенадцати факторов хранит конфигурацию в переменных окружения (часто сокращается до env vars или env). Переменные окружения легко изменить между развёртываниями, не изменяя код; в отличие от файлов конфигурации, менее вероятно случайно сохранить их в репозиторий кода; и в отличие от пользовательских конфигурационных файлов или других механизмов конфигурации, таких как Java System Properties, они являются независимым от языка и операционной системы стандартом.
Другим подходом к управлению конфигурациями является группировка. Иногда приложения группируют конфигурации в именованные группы (часто называемые “окружениями”) названые по названию конкретного развёртывания, например как development, test и production окружения в Rails. Этот метод не является достаточно масштабируемым: чем больше различных развёртываний приложения создаётся, тем больше новых имён окружений необходимо, например staging и qa. При дальнейшем росте проекта, разработчики могут добавлять свои собственные специальные окружения, такие как joes-staging, в результате происходит комбинаторный взрыв конфигураций, который делает управление развёртываниями приложения очень хрупким.
В приложении двенадцати факторов переменные окружения являются не связанными между собой средствами управления, где каждая переменная окружения полностью независима от других. Они никогда не группируются вместе в “окружения”, а вместо этого управляются независимо для каждого развёртывания. Эта модель которая масштабируется постепенно вместе с естественным появлением большего количества развёртываний приложения за время его жизни.

IV. Сторонние службы (Backing Services)

Считайте сторонние службы (backing services) подключаемыми ресурсами

Сторонняя служба– это любая служба, которая доступна приложению по сети и необходима как часть его нормальной работы. Например, хранилища данных (например, MySQL и CouchDB), системы очередей сообщений (например, RabbitMQ и Beanstalkd), службы SMTP для исходящей электронной почты (например, Postfix) и кэширующие системы (например, Memcached).
Традиционно, сторонние службы, такие как базы данных, поддерживаются тем же самым системным администратором, который разворачивает приложение. Помимо локальных сервисов приложение может использовать сервисы, предоставленные и управляемые третьей стороной. Примеры включают в себя SMTP сервисы (например Postmark), сервисы сбора метрик (такие как New Relic и Loggly), хранилища бинарных данных (например, Amazon S3), а также использование API различных сервисов (таких как Twitter, Google Maps и Last.fm).
Код приложения двенадцати факторов не делает различий между локальными и сторонними сервисами. Для приложения каждый из них является подключаемым ресурсом, доступным по URL-адресу или по другой паре расположение/учётные данные, хранящимися в конфигурации. Каждое развёртывание приложения двенадцати факторов должно иметь возможность заменить локальную базу данных MySQL на любую управляемую третьей стороной (например Amazon RDS) без каких либо изменений кода приложения. Аналогичным образом, локальный SMTP сервер может быть заменён сторонним (например Postmark) без изменения кода. В обоих случаях необходимо изменить только идентификатор ресурса в конфигурации.
Каждая различная сторонняя служба является ресурсом. Например, база данных MySQL является ресурсом, две базы данных MySQL (используются для фрагментации на уровне приложения) квалифицируются как два отдельных ресурса. Приложение двенадцати факторов считает эти базы данных подключёнными ресурсами, что указывает на их слабое связывание с развёртыванием, в котором они подключены.
Рабочее развёртывание приложения, подключённого к 4 сторонним сервисам.
Ресурсы можно по необходимости подключать к развёртыванию и отключать от развёртывания. Например, если база данных приложения функционирует некорректно из-за аппаратных проблем, администратор может запустить новый сервер базы данных, восстановленный из последней резервной копии. Текущая рабочая база данных может быть отключена, а новая база данных подключена – всё это без каких-либо изменений кода.

V. Сборка, релиз, выполнение

Строго разделяйте стадии сборки и выполнения

Кодовая база трансформируется в развёртывание (не учитывая развёртывание для разработки) за три этапа:
  • Этап сборки – это трансформация, которая преобразует репозиторий кода в исполняемый пакет, называемый сборка. Используя версию кода по указанному процессом развёртывания коммиту, этап сборки загружает сторонние зависимости и компилирует двоичные файлы и ресурсы (assets).
  • Этап релиза принимает сборку, полученную на этапе сборки, и объединяет её с текущей конфигурацией развёртывания. Полученный релиз содержит сборку и конфигурацию и готов к немедленному запуску в среде выполнения.
  • Этап выполнения (также известный как “runtime”) запускает приложение в среде выполнения путём запуска некоторого набора процессов приложения из определённого релиза.
Код становится сборкой, которая объединяется с конфигурацией для создания релиза.
Приложение двенадцати факторов использует строгое разделение между этапами сборки, релиза и выполнения. Например, невозможно внести изменения в код во время выполнения, так как нет способа распространить эти изменения обратно на этап сборки.
Инструменты развёртывания, как правило, представляют собой инструменты управления релизами, и что немаловажно, дают возможность отката к предыдущему релизу. Например инструмент развёртывания Capistrano сохраняет релизы в подкаталогах каталога с именем releases, где текущий релиз является символической ссылкой на каталог текущего релиза. Команда Capistrano rollback даёт возможность быстро откатится к предыдущему релизу.
Каждый релиз должен иметь уникальный идентификатор, такой как отметка времени релиза (например 2015-04-06-15:42:17) или увеличивающееся число (например v100). Релизы могут только добавляться и каждый релиз невозможно изменить после его создания. Любые изменения обязаны создавать новый релиз.
Сборка инициируется разработчиком приложения всякий раз, когда разворачивается новый код. Запуск этапа выполнения, напротив, может происходить автоматически в таких случаях, как перезагрузка сервера, или перезапуск упавшего процесса менеджером процессов. Таким образом, этап выполнения должен быть как можно более технически простым, так как проблемы, которые могут помешать приложению запуститься могут возникнуть в середине ночи, когда нет доступных разработчиков. Этап сборки может быть более сложным, так как возможные ошибки всегда видимы разработчику, который запустил развёртывание.

VI. Процессы

Запускайте приложение как один или несколько процессов, не сохраняющих внутреннее состояние (stateless)

Приложение выполняется в среде выполнения как один или несколько процессов.
В простейшем случае код является независимым скриптом, среда выполнения – ноутбуком разработчика с установленной средой исполнения языка, а процесс запускается из командной строки (например, как python my_script.py). Другой крайний вариант – это рабочее развёртывание сложного приложения, которое может использовать много типов процессов, каждый из которых запущен в необходимом количестве экземпляров.
Процессы приложения двенадцати факторов не сохраняют внутреннее состояние (stateless) и не имеют разделяемых данных (share-nothing). Любые данные, которые требуется сохранить, должны быть сохранены в хранящей состояние сторонней службе, обычно, в базе данных.
Память и файловая система процесса может быть использована в качестве временного кэша для одной транзакции. Например, загрузка, обработка и сохранение большого файла в базе данных. Приложение двенадцати факторов не предполагает, что что-либо закэшированное в памяти или на диске будет доступно следующим запросам или задачам – с большим количеством разноплановых процессов высока вероятность, что следующий запрос будет обработан другим процессом. Даже с одним запущенным процессом перезапуск (вызванный развёртыванием, изменением конфигураций или переносом процесса на другое физическое устройство) приведёт к уничтожению всех локальных (памяти, файловой системы) состояний.
Упаковщики ресурсов (asset) (например, Jammit или django-compressor) используют файловую систему как кэш для скомпилированных ресурсов. Приложение двенадцати факторов предпочитает делать данную компиляцию во время этапа сборки, например, как в Rails asset pipeline, а не во время выполнения.
Некоторые веб-системы полагаются на “липкие сессии” – то есть кэшируют данные пользовательских сессии в памяти процесса приложения и ожидают того, что последующие запросы того же пользователя будут перенаправлены к тому же процессу. Липкие сессии являются нарушением двенадцати факторов и их никогда не следует использовать или полагаться на них. Данные пользовательской сессии являются хорошими кандидатами для хранилища данных, которое предоставляет функцию ограничения времени хранения, например, Memcached и Redis.

VII. Привязка портов (Port binding)

Экспортируйте сервисы через привязку портов

Иногда веб-приложения запускают внутри контейнера веб-сервера. Например, PHP-приложение может быть запущено как модуль внутри Apache HTTPD, или Java-приложение может быть запущено внутри Tomcat.
Приложение двенадцати факторов является полностью самодостаточным и не полагается на инъекцию веб-сервера во время выполнения для того, чтобы создать веб-сервис. Веб-приложение экспортирует HTTP-сервис путём привязки к порту и прослушивает запросы, поступающих на этот порт.
Во время локальной разработки разработчик переходит по URL-адресу вида http://localhost:5000/, чтобы получить доступ к сервису, предоставляемым его приложением. При развёртывании слой маршрутизации обрабатывает запросы к общедоступному хосту и перенаправляет их к привязанному к порту веб приложению.
Это обычно реализуется с помощью объявления зависимости для добавления библиотеки веб-сервера к приложению такой, как Tornado в Python, Thin в Ruby, и Jetty в Java и других языках на основе JVM. Это происходит полностью в пространстве пользователя, то есть в коде приложения. Контрактом со средой исполнения является привязка приложения к порту для обработки запросов.
HTTP – это не единственный сервис, который может быть экспортирован посредством привязки порта. Почти любой тип серверного ПО может быть запущен как процесс, привязанный к порту и ожидающий входящих запросов. Примеры этого включают ejabberd (предоставляет XMPP протокол) и Redis (предоставляет Redis протокол).
Также обратите внимание, что подход привязки к порту означает, что одно приложение может выступать сторонней службой для другого приложения путём предоставления URL-адреса стороннего приложения как идентификатор ресурса в конфигурации потребляющего приложения.

VIII. Параллелизм

Масштабируйте приложение с помощью процессов

Любая компьютерная программа после запуска представляет собой один или несколько работающих процессов. Исторически веб-приложения принимали различные формы выполнения процессов. К примеру, PHP-процессы выполнятся как дочерние процессы Apache и запускаются по требованию в необходимом для обслуживания поступивших запросов количестве. Java-процессы используют противоположный подход, JVM представляет собой один монолитный мета-процесс, который резервирует большой объём системных ресурсов (процессор и память) при запуске и управляет параллельностью внутри себя с помощью нитей исполнения (threads). В обоих случаях запущенные процессы лишь минимально видны для разработчика приложения.
Масштабирование выражается в количестве запущенных процессов, различие рабочей нагрузки выражается в типах процессов.
В приложении двенадцати факторов процессы являются сущностями первого класса. Процессы в приложении двенадцати факторов взяли сильные стороны из модели процессов Unix для запуска демонов. С помощью этой модели разработчик может спроектировать своё приложение таким образом, что для обработки различной рабочей нагрузки необходимо назначить каждому типу работы своего типа процесса. Например, HTTP-запросы могут быть обработаны веб-процессом, а длительные фоновые задачи обработаны рабочим процессом.
Это не исключает возможность использования внутреннего мультиплексирования для индивидуальных процессов через потоки выполнения виртуальной машины или асинхронные/событийные модели в инструментах таких, как EventMachine, Twisted и Node.js. Но каждая индивидуальная виртуальная машина может масштабироваться только ограничено (вертикальное масштабирование), поэтому приложение должно иметь возможность быть запущенным как несколько процессов на различных физических машинах.
Модель, построенная на процессах, действительно сияет, когда приходит время масштабирования. Отсутствие разделяемых данных и горизонтальное разделение процессов приложения двенадцати факторов означает, что добавление большего параллелизма является простой и надёжной операцией. Массив процессов различного типа и количество процессов каждого типа называются формированием процессов (process formation).
Процессы приложения двенадцати факторов никогда не должны демонизироваться и записывать PID файлы. Вместо этого они должны полагаться на менеджер процессов операционной системы (например, Upstart, распределённый менеджер процессов на облачной платформе, или инструмент как Foreman в процессе разработки) для управления потоком вывода, реагирования на падения процесса и обработки инициированных пользователем перезагрузки или завершения работы.

IX. Утилизируемость (Disposability)

Максимизируйте надёжность с помощью быстрого запуска и корректного завершения работы

Процессы приложения двенадцати факторов являются утилизируемыми, это означает, что они могут быть запущены и остановлены в любой момент. Это способствует стабильному и гибкому масштабированию, быстрому развёртыванию изменений кода и конфигураций и надёжности рабочего развёртывания.
Процессы должны стараться минимизировать время запуска. В идеале процесс должен затратить всего несколько секунд от момента времени, когда выполнена команда запуска, и до того момента, когда процесс запущен и готов принимать запросы или задачи. Короткое время запуска предоставляет большую гибкость для релиза и масштабирования. Кроме того, это более надёжно, так как менеджер процессов может свободно перемещать процессы на новые физические машины при необходимости.
Процессы должны завершаться корректно, когда они получают SIGTERM сигнал от диспетчера процессов. Для веб-процесса корректное завершение работы достигается путём прекращения прослушивания порта сервиса (таким образом, отказаться от каких-либо новых запросов), что позволяет завершить текущие запросы и затем завершиться. В этой модели подразумевается, что HTTP-запросы короткие (не более чем на несколько секунд), в случае длинных запросов клиент должен плавно попытаться восстановить подключение при потере соединения.
Для процесса, выполняющего фоновые задачи (worker), корректное завершение работы достигается путём возвращения текущей задачи назад в очередь задач. Например, в RabbitMQ рабочий процесс может отправлять команду NACK; в Beanstalkd задача возвращается в очередь автоматически, когда рабочий процесс отключается. Системы, основанные на блокировках такие, как Delayed Job должны быть уведомлены, чтобы освободить блокировку задачи. В этой модели подразумевается, что все задачи являются повторно входимыми, что обычно достигается путём оборачивания результатов работы в транзакции или путём использования идемпотентных операций.
Процессы также должны быть устойчивыми к внезапной смерти в случае отказа аппаратного обеспечения. Хотя это менее вероятное событие, чем корректное завершение работы сигналом SIGTERM, оно всё же может случиться. Рекомендуемым подходом является использование надёжных очередей задач, таких как Beanstalkd, которые возвращают задачу в очередь когда клиент отключается или превышает лимит времени. В любом случае приложение двенадцати факторов должно проектироваться так, чтобы обрабатывать неожиданные и неизящные выключения. Архитектура только аварийного выключения (Crash-only design) доводит эту концепцию до её логического завершения.

X. Паритет разработки/работы приложения

Держите окружения разработки, промежуточного развёртывания (staging) и рабочего развёртывания (production) максимально похожими

Исторически существуют значительные различия между разработкой (разработчик делает живые изменения на локальном развёртывании приложения) и работой приложения (развёртывание приложения с доступом к нему конечных пользователей). Эти различия проявляются в трёх областях:
  • Различие во времени: разработчик может работать с кодом, который попадёт в рабочую версию приложения только через дни, недели или даже месяцы.
  • Различие персонала: разработчики пишут код, OPS инженеры разворачивают его.
  • Различие инструментов: разработчики могут использовать стек технологий, такой как Nginx, SQLite, и OS X, в то время как при рабочем развёртывании используются Apache, MySQL и Linux.
Приложение двенадцати факторов спроектировано для непрерывного развёртывания благодаря минимизации различий между разработкой и работой приложения. Рассмотрим три различия, описанных выше:
  • Сделать различие во времени небольшим: разработчик может написать код, и он будет развёрнут через несколько часов или даже минут.
  • Сделать небольшими различия персонала: разработчик который написал код, активно участвует в его развёртывании и наблюдает за его поведением во время работы приложения.
  • Сделать различия инструментов небольшими: держать окружение разработки и работы приложения максимально похожими.
Резюмируя сказанное выше в таблицу:
Традиционное приложениеПриложение двенадцати факторов
Время между развёртываниямиНеделиЧасы
Автор кода/тот кто разворачиваетРазные людиТе же люди
Окружение разработки/работы приложенияРазличныеМаксимально похожие
Сторонние службы, такие как базы данных, системы очередей сообщений и кэш, являются одной из областей, где паритет при разработке и работе приложения имеет важное значение. Многие языки предоставляют библиотеки, которые упрощают доступ к сторонним службам, включая адаптеры для доступа к различных типам сервисов. Некоторые примеры, в таблице ниже.
ТипЯзыкБиблиотекаАдаптеры
База данныхRuby/RailsActiveRecordMySQL, PostgreSQL, SQLite
Очередь сообщенийPython/DjangoCeleryRabbitMQ, Beanstalkd, Redis
КэшRuby/RailsActiveSupport::CacheПамять, файловая система, Memcached
Иногда разработчики находят удобным использовать лёгкие сторонние службы в их локальном окружении, в то время как более серьёзные и надёжные сторонние сервисы будут использованы в рабочем окружении. Например используют SQLite локально и PostgreSQL в рабочем окружении; или память процесса для кэширования при разработке и Memcached в рабочем окружении.
Разработчик приложения двенадцати факторов сопротивляется искушению использовать различные сторонние сервисы при разработке и в рабочем окружении, даже когда адаптеры теоретически абстрагированы от различий в сторонних сервисах. Различия в используемых сторонних сервисах означают, что может возникнуть крошечная несовместимость, которая станет причиной того, что код, который работал и прошёл тесты при разработке и промежуточном развёртывании не работает в рабочем окружении. Такой тип ошибок создаёт помехи, которые нивелируют преимущества непрерывного развёртывания. Стоимость этих помех и последующего восстановления непрерывного развёртывания является чрезвычайно высокой, если рассматривать в совокупности за всё время существования приложения.
Установка локальных сервисов стала менее непреодолимой задачей, чем она когда-то была. Современные сторонние сервисы, такие как Memcached, PostgreSQL и RabbitMQ не трудно установить и запустить благодаря современным менеджерам пакетов, таким как Homebrew и apt-get. Кроме того, декларативные инструменты подготовки окружения, такие как Chef и Puppet в сочетании с легковесным виртуальным окружением, таким как Vagrant позволяют разработчикам запустить локальное окружение которое максимально приближено к рабочему окружению. Стоимость установки и использования этих систем ниже по сравнению с выгодой, получаемой от паритета разработки/работы приложения и непрерывного развёртывания.
Адаптеры для различных сторонних сервисов по-прежнему полезны, потому что они позволяют портировать приложение для использования новых сторонних сервисов относительно безболезненно. Но все развёртывания приложения (окружение разработчика, промежуточное и рабочее развёртывание) должны использовать тот же тип и ту же версию каждого из сторонних сервисов.

XI. Журналирование (Logs)

Рассматривайте журнал как поток событий

Журналирование обеспечивает наглядное представление поведения работающего приложения. Обычно в серверной среде журнал записывается в файл на диске (“logfile”), но это только один из форматов вывода.
Журнал – это поток агрегированных, упорядоченных по времени событий, собранных из потоков вывода всех запущенных процессов и вспомогательных сервисов. Журнал в своём сыром виде обычно представлен текстовым форматом с одним событием на строчку (хотя трассировки исключений могут занимать несколько строк). Журнал не имеет фиксированного начала и конца, поток сообщений непрерывен, пока работает приложение.
Приложение двенадцати факторов никогда не занимается маршрутизацией и хранением своего потока вывода. Приложение не должно записывать журнал в файл и управлять файлами журналов. Вместо этого каждый выполняющийся процесс записывает свой поток событий без буферизации в стандартный вывод stdout. Во время локальной разработки разработчик имеет возможность просматривать этот поток в терминале, чтобы наблюдать за поведением приложения.
При промежуточном и рабочем развёртывании поток вывода каждого процесса будет захвачен средой выполнения, собран вместе со всеми другими потоками вывода приложения и перенаправлен к одному или нескольким конечным пунктам назначения для просмотра и долгосрочной архивации. Эти конечные пункты архивации не являются видимыми для приложения и настраиваемыми приложением, вместо этого они полностью управляются средой выполнения. Маршрутизаторы журналов с открытым исходным кодом (например, Logplex и Fluent) могут быть использованы для этой цели.
Поток событий приложения может быть перенаправлен в файл или просматриваться в терминале в режиме реального времени. Наиболее значимым является то, что поток событий может быть направлен в систему индексирования и анализа журналов, такую как Splunk, или систему хранения данных общего назначения, такую как Hadoop/Hive. Эти системы обладают большими возможностями и гибкостью для досконального анализа поведения приложение в течении времени, что включает в себя:
  • Поиск конкретных событий в прошлом.
  • Крупномасштабные графики трендов (например, запросов в минуту).
  • Активные оповещения согласно эвристическим правилам, определяемых пользователем (например, оповещение, когда количество ошибок в минуту превышает определённый порог).

XII. Задачи администрирования

Выполняйте задачи администрирования/управления с помощью разовых процессов

Формирование процессов является некоторым набором процессов, которые необходимы для выполнения регулярных задач приложения (таких как обработка веб-запросов), когда оно исполняется. В дополнение к этому, разработчикам периодически необходимо выполнять разовые задачи администрирования и обслуживания приложения, такие как:
  • Запуск миграции базы данных (например manage.py migrate в Django, rake db:migrate в Rails).
  • Запуск консоли (также известной как оболочка REPL), чтобы запустить произвольный код или проверить модели приложения с действующей базой данных. Большинство языков предоставляют REPL путём запуска интерпретатора без каких-либо аргументов (например, python или perl), а в некоторых случаях имеют отдельную команду (например irb в Ruby, rails console в Rails).
  • Запуск разовых скриптов, хранящихся в репозитории приложения (например, php scripts/fix_bad_records.php).
Разовые процессы администрирования следует запускать в среде идентичной регулярным длительным процессам приложения. Они запускаются на уровне релиза, используя те же кодовую базу и конфигурацию, как и любой другой процесс, выполняющий этот релиз. Код администрирования должен поставляться вместе с кодом приложения, чтобы избежать проблем синхронизации.
Те же самые методы изоляции зависимостей должны быть использованы для всех типов процессов. Например, если веб-процесс Ruby использует команду bundle exec thin start, то для миграции базы данных следует использовать bundle exec rake db:migrate. Аналогичным образом для программы на Python с использованием Virtualenv следует использовать поставляемый bin/python как для запуска веб-сервера Tornado, так и для запуска любых manage.py процессов администрирования.
Методология двенадцати факторов отдаёт предпочтение языкам, которые предоставляют REPL оболочки из коробки, и которые позволяют легко выполнять разовые скрипты. В локальном развёртывании разработчики выполняют разовый процесс администрирования с помощью консольной команды внутри каталога с приложением. В рабочем развёртывании разработчики могут использовать ssh или другой механизм выполнения удалённой команды, предоставленный средой выполнения, для запуска такого процесса.

вторник, 26 сентября 2017 г.

Признаки эффективной команды

Признаки успешной команды



Общее понимание целей и задач, стоящих перед командой

  • Общее понимание цели и миссии: могут ли члены команды ответить на вопрос «Для чего мы тут собрались?»
  • Общее понимание необходимости решения задач, стоящих перед командой.
  • Четкие цели и задачи: понимание целей и задач, которые пытается реализовать команда.
  • Подходящие цели: все ли согласны с тем, что цели подходят команде, установлены конкретные сроки реализации.


Четкое распределение функций и обязанностей

  • Понимание каждым членом команды своего вклада в достижение цели; понимание всеми обязанностей и функций других членов команды.
  • Понимание всеми показателей оценки результативности.
  • Общее понимание рисков и проблем.
  • Общее понимание критически важных факторов успеха.


Эффективное использование командных процессов

  • Понятный метод оценки достижений.
  • Понятные критерии оценки достигнутого прогресса.
  • Понятный процесс принятия решения.
  • Понятный процесс выявления проблем и их решения.


Хорошие взаимоотношения в команде.

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


Хорошее управление внешними связями

  • Понятные каналы коммуникации
  • Понятные места сбора, проведения совещаний, дискуссий, обмена мнениями.


пятница, 22 сентября 2017 г.

Восприятие

А сама энергия и есть способность воздействовать, 
измеряемая, 
когда воздействие произведено.
В.Пелевин. Бубен нижнего мира.

Восприятие?
Воспринимаем ли мы мир таким каков он есть?
Ограниченность органов чувств заставляет усомниться в отображении 1 к 1 реального мира.
Реальность конечно отражается посредством рецепторов, но затем преобразуется в некоторую конструкцию, которая затем интерпретируется, "сжимается", систематизируется и сохраняется в области, именуемой как сознательным, так и бессознательным атрибутом высшей нервной деятельности.
Прилагательное "высшей" может отражать также и иронию по отношению к восприятию мира, обозначая несостоятельность восприятия мира в некоторой совокупности его характеристик, не говоря уже о полноте восприятия. Она, высшая нервная деятельность, порождает теории сверхчувственного и трансцендентного (включая эзотерическое). К таким теориям можно относится с пренебрежением, но ограниченность восприятия, а главное сколь-нибудь убедительное свидетельствование в пользу непосредственности восприятия окружающей действительности, заставляет усомниться в отсутствии возможности познания чего-либо вне рамок восприятия.

Восприятие настолько порой настолько парадоксально, что исследование не укладывается в рамки какой-либо дисциплины. Судите сами, вот неполный, не тем не менее внушительный перечень подходов к изучению восприятия:

  • Эмпиризм (опыт).
  • Структуализм (фигура сумма точек).
  • Гештальт-психология.
  • Конструктивизм. (Восприятию предшествует конструкт, концепция?)
  • Информационный подход.
  • Нейрофизиологический подход.
  • Когнитивная нейрология. (Устройство мозга).
Даже в таком вопросе определения признаков, дающих возможность узнавать и идентифицировать объекты нет полной ясности.

Например, согласно Б. Джулезу, существуют некоторые простейшие элементы текстуры — текстоны, которые представляют собой специфические, различимые характеристики элементов.

К ним относятся:
  • форма;
  • кривизна;
  • линейные сегменты;
  • ширина;
  • высота;
  • соединения частей;
  • углы наклона;
  • углы пересечения разных наклонов.
Чем больше отличаются друг от друга текстоны разных элементов, тем проще отличить друг от друга и сами элементы.

Или, например, теория распознавания по компонентам И. Бидермана.
Распознавание объекта начинается с обработки информации о наборе примитивных отличительных признаков. Любой воспринимаемый трехмерный предмет может быть разложен на ряд элементарных составляющих — геометрических модулей, или компонентов, называемых геонами («геометрическими ионами»).
Существует 24 базовых геона. Комбинируя их в разных вариантах можно получить объект практически любой формы. 
Для узнавания предмета достаточно трех его геонов.

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

понедельник, 18 сентября 2017 г.

Парадоксы взаимозависимости

Коллективная работа, помимо положительных "синергетических" эффектов, сопряжена с негативными "синергетическими" эффектами, связанными с условиями взаимозависимости.

Отрицательные эффекты взаимозависимости могут быть описаны двумя типами проблем:
  • проблема второго (третьего и т.д.) босса - начальствующего менеджера;
  • проблема нерасторопного смежника, если ваша работа зависит от лепты смежника.
Исключить эти проблемы из деятельности менеджера невозможно в принципе.

Смягчение последствий "второго начальника" может быть произведена за счет следующих мер:
  1. Постоянный менеджер должен обсудить со втором боссом подчиненного проблему "второго босса", вежливо и по деловому и наметить меры смягчения негативных последствий:
    1. кто должен контролировать работу подчененного для соблюдения принципа: у подчиненного должен быть один начальник;
    2. как и кем будет расспределять рабочее время подчиненного;
    3. кто будет оценивать количество и качество работы подчиненного.
  2. Следует обучить подчиненного сообщать начальствующим менеджерам о получаемых заданиях "боссов" и уточнять у них: когда и кому подчиненный должен отчитываться.
  3. Кто-то один из начальников (по умолчанию, постоянный менеджер подчиненного) должен устанавливать приоритетность заданий, доводить приоритет до подчиненного с обязательной проверкой того, что подчиненный понял приоритет и принял к исполнению.
  4. Четко определять (а подчиненному - выяснять) параметры задания и время, потребное на его выполнение.
  5. Убедиться, что подчиненный, выполняя задание другого менеджера, понимает и знает стандарты, требования и правила, принятые у другого менеджера.
Первый руководитель (постоянный менеджер) всегда имеет массу инструментов влияния и мотивирования подчиненного, работающего под прессом другого менеджера. Для этого нужно внимательно следить за работой подчиненного и нацеливать его на успех, обсуждать с подчиненным проблемы и препятствия, которые могут помешать подчиненному выполнить задания и поручения.

Вторая проблема - нерасторопность смежников. Вам приходится ждать пока смежник внесет свою лепту в общее дело. Эта проблема не решается непосредственно вами, так как у вас нет полномочий влиять на смежника. Более того, ваш смежник может иметь более высокое положение, чем вы.

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

четверг, 14 сентября 2017 г.

Список динамических способностей организации


В трактовке Д.Тиса (D.J. Teece / Д. Дж. Тис — Динамические способности и стратегический менеджмент) динамические способности организации описываются следующими группами умений:
  • Рутинные процессы управления инновациями.
  • Бизнес-интуиция, видение, необходимые для создания новых бизнес-моделей.
  • Умение принимать верные инвестиционные решения: умение выявлять новые рынки, новые технологии; умение работать (ограничивать) с неопределенностью; умение сочетать активы для достижения эффектов.
  • Компетенции управления транзакциями.
Одной из новаций в стратегическом менеджменте стала концепция стратегии, основанной на развитии динамических способностей организации.

Концепция в этом случае будет состоять в
  • генерации,
  • оценке,
  • развитии
динамических способностей организации.

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

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

Принцип, лежащих в основе стратегии, - стратегическое планирование и моделирование развития организации на основе
  • генерации,
  • оценки,
  • развития
динамических способностей организации.

Однако, неплохо бы иметь как можно более обширный список динамических способностей, чтобы выбирать из этого списка, а не ломать голову, какие же они бывают - динамические способности.

Поэтому наша цель, сформировать такой список.

Способность к предприимчивости

Можно охарактеризовать как "диалектическое противоречие" между необходимостью поиска нового и использования существующего потенциала организации. Разрешение данного противоречия производится посредством решения проблем поддержания эффективности бизнеса путем постоянной адаптации бизнеса к быстрым изменениям рынка. Содержит
  • организационное омоложение,
  • стратегическое обновление,
  • пересмотр сфер деятельности,
  • реконструкция бизнес-моделей,
  • усточивое развитие в условиях рисков, связанных с разработкой новых рынков, продуктов, идей.
 Критерий, определяющий наличие способности - обеспечение деятельности компании в рискованной или безвыходной ситуации.

Способность к организационному обновлению

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

Способность к инновационной активности

Способность разрабатывать и внедрять новые продукты, услуги и технологии, способность обновлять знания, технологии, оборудование, способность эффектино использовать новое, быть восприимчивым к новому. Содержит
  • процессы реагирования на вызовы рынка,
  • восприимчивость к техническим и организационным новшествам,
  • способность создавать, внедрять и монетизировать новации и инновации.
Критерий, определяющий наличие способности - осуществление инновационной стратегии с актуализацией инвестиционного потенциала.

Способность к изменениям

Способность к трансформации текущей позиции орагнизации на основе изменения и реконфигурации ресурсов и способностей фирмы в связи с ситуацией на рынке. Содержит
  • возможность распознования проблем и тенденций,
  • видение новых возможностей для развития.
Критерий, определяющий наличие способности - эффективная адаптация организации к условиям внешней среды.

Способность к созданию высокого качества

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

Критерий, определяющий наличие способности - выпуск высококачественной продукции/услуг.

Способность к стратегическому мышлению

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

Критерий, определяющий наличие способности - реализация стратегии.

Способность к управлению знаниями

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

Способность к управлению ростом

Способность осуществлять увеличение масштаба, видов и сложностей деятельности фирмы. Содержит
  • идентификация причинно-следственных связей факторов скорости формирования стоимости,
  • структурирование стратегических и тактических целей по управленческим перспективам роста,
  • разработку ключевых экономических показателей роста с декомпозией по уровням управления.
Критерий, определяющий наличие способности - увеличение масштабов, видов и сложностей бизнеса.

воскресенье, 10 сентября 2017 г.

Стратегия развития способностей

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

Что есть динамические способности организации?

Сошлемся на работу "Динамические способности и стратегическая архитектура компании". Неретина Е.А.


Во-первых, что есть способность в данном контексте.

Под способностью принято понимать потенциал ресурсов в осуществлении определенной задачи или деятельности.
Во-вторых, в работе замечено, что концепция динамических способностей синомична концепции интеллектуального потенциала фирма, например, согласно мнению ряда зарубежных ученых (Д. Тиса, Г. Пизано, Э. Шуена и др.).

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

В третьих, способность к изменениям – это главное в концепции динамических способностей.

Динамические способности организации можно охарактеризовать как потенциальные способности организации обновляться в соответствии с изменениями во внешней среде. Динамические способности организации позволяют объединять, создавать и реконфигурировать внешние и внутренние компетенции компании.

Корпоративная стратегия компаний, использующих концепцию динамических способностей базируется на бизнес-процессах, а не на товарах и рынках.
Для формирования динамических способностей компания должна делать стратегические инвестиции в человеческие ресурсы, в поддерживающую инфраструктуру и современные информационные технологии. В свою очередь, динамические способности с одной стороны связывают связать воедино, а с другой стороны размывают границы традиционно сложившейся организационной структуры и сложившихся функций управления.

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

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

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

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

Принцип, лежащих в основе стратегии, - стратегическое планирование и моделирование развития организации на основе
  • генерации,
  • оценки,
  • развития
динамических способностей организации.

Обоснования необходимости разработки

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

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

Примеры динамических способностей

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

Ораганизационные способности к изменениям могут быть сведены в три группы:
  • Наличные способности развития
  • Способности организационно оформить и довести до ключевых агентов развитие (изменения).
  • Способности проведения и поддержания изменений в эффективном ключе.
Наличные способности развития могут описывать наличием как минимум результативных, как максимум эффективных способностей, выражающих в проведении следующих действий (активностей):
  • Умение проводить оценку эффективности организационного развития организации.
  • Умение проводить оценку эффективности инновационной деятельности в ходе реализации проектов организационного развития.
  • Умение оценивать готовность персонала к изменениям, выявление наличия необходимых знаний и навыков, умение оценивать моральную готовность организации к изменениям.
  • Умение оценивать готовность организационной структуры к изменениям.
  • Умение оценивать систему коммуникаций.
  • Умение оценивать осуществимость инициативы организационных изменений.
  • Умение проводить анализ потребностей групп, заинтересованных и незаинтересованных в организационном развитии.
Для реализации данного группы способностей организация должна:
  • Иметь методику выстраивания инновационной архитектуры организации.
  • Иметь модель реализации организационного проекта развития инновационной деятельности организации.
  • Уметь формировать инновационных портфель организации.
  • Иметь навыки и методику управления организационным проектом развития.
  • Владеть методами управления НИОКР организации.
  • Иметь и уметь использовать модели управления НИОКР-ми.
  • Владеть методами сегментирования бизнеса фирмы.

Способности организационно оформить и довести до ключевых агентов развитие (изменения) могут описывать наличием как минимум результативных, как максимум эффективных способностей, выражающих в проведении следующих действий (активностей):
  • Умение проводить оценку "интеллектуальной собственности" организации.
  • Умение оценивать творческий потенциал организации.
  • Выявление доминирующих мотивационных установок для решения перспективных задач.
  • Умение проводить оценку кадрового потенциала организации.
  • Наличие и проведение оценок эффективности использования организационного потенциала организации.
  • Умение оценивать уровень обученности и обучаемости персонала организации.
Для реализации данного группы способностей организация должна:
  • Уметь формировать систему управления знаниями.
  • Организовывать и поддерживать творческой деятельности.
  • Создавать творческую атмосферу в коллективе.
  • Образовывать временные творческие группы для решения проблем.
  • Уметь и применять регламентные технологии организационного развития.
  • Развивать организационных потенциал организации.
  • Развивать способности персонала к изменениям.

Способности проведения и поддержания изменений в эффективном ключе могут описывать наличием как минимум результативных, как максимум эффективных способностей, выражающих в проведении следующих действий (активностей):
  • Анализ инвестиционной деятельности.
  • Оценка темпов и пропорций роста.
  • Оценка и прогнозирование организации и рынка.
  • Оценка и прогнозирование объемов выпуска и реализации.
  • Прогнозирование уровня качества продукции/услуг организации.
  • Оценка устойчивости (развития) организации.
  • Оценка результативности стратегического управления.
  • Оценка бизнес-модели организации, включая анализ структуры денежных потоков.
Для реализации данного группы способностей организация должна уметь:
  • Моделировать темпы и пропорции роста.
  • Моделировать организационной стратегии.
  • Моделировать параметры инвестиционной привлекательности организации.
  • Применять "продвинутые" технологии принятия решений.
  • Согласовывать стратегии бизнеса и стратегии организационного управления.
  • Управлять стратегическими задачами.
  • Иметь и применять методики разработки стратегии организационного развития.
  • Иметь и применять методики приведения организационной стратегии с соответствие со стратегий развития организации.

пятница, 8 сентября 2017 г.

Свобода выбора

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

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

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

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

* * *

Контрдовод:

Жизнь похожа на игру в рулетку. Сначала ты выигрываешь раз, другой, третий. Ты воображаешь себя победителем, тебе кажется, что весь мир у тебя в кармане. Но в конечном итоге, ты всегда остаешься в проигрыше. Ты всего лишь гусь на празднике, которого откармливают, чтобы потом зажарить и съесть под звуки веселой музыки и смеха. Ты ошибся, это не твой праздник. Ты ошибся…