17. Анализ возникающих на предприятии узких мест.

18. Методы расчета инвестиций.

19.Расчет производственного результата на краткосрочный период.

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

22.Кружки качества.

23. Анализ скидок.

24. Анализ областей сбыта.

25. Функционально-стоимостной анализ.

26. Xyz-анализ.

27. Собственное производство - поставки со стороны.

28. Кривая опыта.

29. Анализ конкуренции.

30. Логистика.

31. Портфельный анализ.

33. Кривая жизненного цикла продукта.

34. Анализ сильных и слабых сторон предприятия.

36. Разработка сценариев.

37. Последовательность этапов проектирования процесса контроллинга в организации.

38. Организационная и эксплуатационная фазы проектирования процесса контроллинга.

40. Социально-психологические факторы сопротивления новой концепции управления на предприятии: групповое сопротивление.

41. Задачи контроллера на предприятии.

42. Требования к профессиональным и личностным свойствам контроллеров.

43. Примеры основных функциональных ролей контроллера.

46. Основные виды организации контроллинга.

47. Варианты позиционирования службы контроллинга.

48. Предпосылки организации службы контроллинга на предприятии.

49. Централизованный и децентрализованный контроллинг.

50. Роль и задачи главного контроллера на предприятии.

51. Концепции контроллинга в отношении задач учета.

52. Место (роль и задачи) децентрализованных контроллеров в структуре предприятия.

53. Преимущества и недостатки создания самостоятельной службы контроллинга в организации.

54. Конфликт контроллера и руководителя: сущность и виды конфликта.

55. Функциональный подход к сбору информации для принятия управленческих решений: недостатки и достоинства.

56. Автоматизация обработки информации при внедрении концепции контроллинга.

Автоматизация.

58. Единое информационное пространство: сущность, необходимость создания (условия), возможности.

59. Интегрированная управленческо-информационная система как инструмент управления на базе эвм. Основные блоки уис и их функции.

61. Eis: назначение, основные характеристики.

62. Ошибочные предпосылки при проектировании уис.

63. Информационный реинжиниринг: сущность, основные этапы.

65. Общеэкономический и конкретно-управленческий смысл планирования деятельности фирмы.

17. Анализ возникающих на предприятии узких мест.

Задача оперативного планирования производственной программы заключается в определении номенклатуры и объемов продукции. Для этого должны быть известны следующие данные:

1) цены на продукцию;

2) затраты на производство продукции;

4) располагаемые производственные мощности.

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

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

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

На предприятии существуют три принципиальных подхода:

а) Отсутствие узких мест.

Поскольку нет узких мест, то производиться может вся продукция.

б) Наличие одного узкого места.

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

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

Если известны выручка от продажи и переменные затраты на единицу продукции, а значит, и сумма покрытия, то оптимальную производственную программу можно сформировать поэтапно Ориентация на величину суммы покрытия позволяет последовательно составлять программу, если есть только одно узкое место.

в) Наличие нескольких узких мест.

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

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

Наличие одного узкого места может объясняться двумя причинами:

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

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

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

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

Сейчас термин bottleneck может использоваться для в любой отрасли — в сфере услуг, разработке программного обеспечения, логистике, повседневной жизни.

Что такое bottleneck

Определение bottleneck звучит как место в производственной системе, в котором возникает перегрузка, потому что поток материалов поступает слишком быстро, но не может быть так же быстро переработан. Часто это станция с меньшей мощностью, чем предыдущий узел. Термин произошел из аналогии с узким горлышком бутылки, которое замедляет путь жидкости наружу.

Bottleneck — узкое место в производственном процессе

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

Существует два типа узких мест:

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

Как определить bottleneck в производственном процессе

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

Очереди и заторы

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

Пропускная способность

Пропускная способность всей производственной линии прямо зависит от выхода оборудования bottleneck. Это характеристика поможет найти главное бутылочное горлышко процесса производства. Увеличение выпуска единицы оборудования, которая не является узким местом, существенно не повлияет на общий выпуск линии. Проверив поочередно все оборудование, можно выявить bottleneck — то есть тот шаг, увеличение мощности которого больше всего повлияет на выход всего процесса.

Полная мощность

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

Ожидание

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

Кроме наблюдения за производством, для выявления узких мест используются такие инструменты:

Value Stream Mapping — карта создания потоков ценности

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

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

Как уменьшить влияние узких мест

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

Первый подход

Увеличение мощности существующих узких мест.

Существует несколько способов увеличить мощность узких мест:

1. Добавьте ресурсы в ограничивающий процесс. Необязательно нанимать новых сотрудников. Кросс-функциональное обучение персонала может уменьшить влияние узких мест с незначительными затратами. В таком случае рабочие будут обслуживать сразу несколько станций и облегчать прохождение узких мест.
2. Обеспечьте бесперебойную подачу деталей на узкое место. Всегда следите за незавершенным производством перед узким местом, управляйте подачей ресурсов на станцию bottleneck, учитывайте овертаймы, в течение которых оборудование также всегда должно иметь детали для обработки.
3. Убедитесь, что узкое место работает только с качественными деталями. Не тратьте мощность и время работы узкого места на обработку брака. Размещайте точки контроля качества перед станциями bottleneck. Это повысит пропускную способность процесса.
4. Проверьте график производства. Если в процессе выпускается несколько разных продуктов, которые требуют разного времени работы bottleneck, скорректируйте график производства так, чтобы общий спрос на bottleneck уменьшился
5. Увеличьте время работы ограничивающего оборудования. Пусть bottleneck работает дольше, чем другое оборудование. Назначьте оператора, который будет обслуживать процесс во время обеденных перерывов, плановых простоев и, если нужно, сверхурочно. Хотя этот метод не уменьшит время цикла, он будет поддерживать работу bottleneck пока остальное оборудование будет простаивать.
6. Сократите простои. Избегайте плановых и внеплановых простоев. Если оборудование bottleneck выйдет из строя во время рабочего процесса, немедленно отправьте ремонтную бригаду, чтобы починить и запустить его. Также постарайтесь сократить время переналадки оборудования с одного продукта на другой.
7. Усовершенствуйте процесс именно в узком месте. Используйте VSM, чтобы устранить действия, не добавляющие ценности, и сократить время на добавление ценности, избавившись от потерь. В итоге вы получите более короткое время цикла.
8. Перераспределите нагрузку на bottleneck. Если возможно, разделите операцию на части и назначьте их на другие ресурсы. В итоге вы получите более короткий цикл и возросшую мощность.

Второй подход

Продажа излишков производства, которые выпускает оборудование, не относящееся к бутылочному горлышку.

Например, у вас на линии 20 инъекционных прессов, а вы используете только 12 из них, потому что оборудование bottleneck не может переработать выпуск всех 20 прессов. В этом случае вы можете найти другие компании, которые заинтересованы в субподряде на операции литья под давлением. Вы будете в прибыли, потому что получите от субподрядчиков больше, чем ваши переменные расходы.

Третий подход

Сокращение неиспользуемой мощности.

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

Примеры bottleneck вне производства

Транспорт

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

Компьютерные сети

Медленный WiFi-роутер, подключенный к эффективной сети с высокой пропускной способностью, является узким местом.

Коммуникация

Разработчик, который шесть часов в день проводит на совещаниях, и только два часа пишет код.

Программное обеспечение

В приложения тоже есть узкие места — это элементы кода, на которых программа «тормозит», заставляя пользователя ждать.

"Железо" компьютера

Узкие места в компьютере — это ограничения аппаратных средств, при которых мощность всей системы ограничивается одним компонентом. Часто процессор рассматривается как ограничивающий компонент для видеокарты.

Бюрократия

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

Вердикт

Узкие места в производстве, менеджменте и жизни — это точки потенциальных улучшений.

Расширение bottleneck даст ощутимый прирост производительности и эффективности.

А не обращать внимания на ограничивающие элементы системы — значит недополучать прибыль и работать хуже своих возможностей.

Существует такая статистика: 20% кода выполняется 80% времени. Точность ее
вряд ли полностью соответствует реальному положению вещей, а вот общий смысл
довольно интересен: получается, что оптимизация всего приложения – занятие
неблагодарное и глупое, а реальные результаты может дать только оптимизация тех
20% приложения, которые выполняются дольше всего. Причем найти эти 20% не так уж
и сложно.

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

Простейшее профилирование можно произвести голыми руками (и ниже я покажу,
как это сделать), однако лучше положиться на сообщество, представители которого
уже создали все необходимые инструменты. Первый и наиболее популярный инструмент
носит имя GNU Profiler (или gprof). Он испокон веков используется для
профилирования кода, генерируемого компилятором GCC. Второй - GNU Coverage
testing tool (gcov), утилита для более детального анализа производительности.
Третий - набор инструментов отладки и профилирования под общим именем Google
Performance Tools (сокращенно GPT). Ну а четвертый - это Valgrind, который хоть
и предназначен для поиска ошибок работы с памятью, но содержит в своем арсенале
ряд утилит для анализа производительности программ.

Начнем, как и полагается, с классики.

GNU Profiler

GNU Profiler (gprof) - один из старейших профайлеров, доступных для
операционных систем типа UNIX. Он входит в состав пакета gcc, и потому может
быть использован для профилирования программ, написанных на любом поддерживаемом
им языке (а это не только C/C++, но и Objective-C, Ada, Java).

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

Рассмотрим, как это работает в реальных условиях. Чтобы ощутить все
достоинства gprof, мы применим ее не к какому-нибудь абстрактному, искусственно
созданному приложению, а к самому настоящему повседневно используемому. Пусть
это будет gzip.

Получаем и распаковываем исходники архиватора:

$ wget www.gzip.org/gzip-1.3.3.tar.gz
$ tar -xzf gzip-1.3.3.tar.gz
$ cd gzip-1.3.3

Устанавливаем инструменты, необходимые для сборки (в Ubuntu это делается
через инсталляцию мета-пакета build-essential):

$ sudo apt-get install build-essential

Запускаем конфигуратор сборки, передав в переменной окружения CFLAGS аргумент
"-pg":

$ CFLAGS="-pg" ./configure

Компилируем программу:

Теперь у нас есть бинарник gzip, способный вести статистику своего
исполнения. Каждый его запуск будет сопровождаться генерацией файла gmon.out:

$ ls -l gmon.out
-rw-r--r-- 1 j1m j1m 24406 2010-11-19 14:47 gmon.out

Этот файл не предназначен для чтения человеком, но может быть использован для
создания подробного отчета об исполнении:

$ gprof ./gzip gmon.out > gzip-profile.txt

Наиболее важная часть полученного файла показана на скриншоте.

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

Попробуем проанализировать отчет. Первой в списке идет функция deflate,
которая была вызвана всего один раз, но "сожрала" 29% всего времени исполнения
программы. Это реализация алгоритма компрессии, и, если бы перед нами стояла
задача оптимизировать gzip, мы должны были бы начать именно с нее. 22% времени
ушло на исполнение функции longest_match, но, в отличие от deflate, она была
вызвана аж 450 613 081 раз, поэтому каждый отдельный вызов функции занимал
ничтожное количество времени. Это второй кандидат на оптимизацию. Функция
fill_window отняла 13% всего времени и была вызвана "всего" 22 180 раз.
Возможно, и в этом случае оптимизация могла бы дать результаты.

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

Столбцы содержат следующую информацию (слева направо): индекс (index, он есть
только в первичной строке и, по сути, ничего не значит); процент времени,
который уходит на выполнение функции (% time); количество времени, затрачиваемое
на ее выполнение в секундах (self); количество времени, затрачиваемое на
выполнение функции и всех вызываемых ею функций (children); количество вызовов
функции (called) и ее имя (name).

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

GNU Coverage testing tool

Кроме gprof, компилятор GCC имеет в своем составе еще один инструмент
профилирования, который позволяет получить более детальный отчет о выполнении
приложения. Утилита называется gcov и предназначена для генерации так
называемого аннотированного исходного кода, который напротив каждой строки
содержит количество ее исполнений. Это может понадобиться для более глубокого
изучения проблем приложения, когда функции, виновные в "тормозах", найдены, а
суть проблемы так и остается неясна (например, непонятно, какая строка в
многократно вложенном цикле внутри длиннющей функции несет ответственность за
аномальное падение производительности).

Gcov не может полагаться на статистику, генерируемую приложением при сборке с
флагом "-pg", и требует пересборки с флагами "-fprofile-arcs" и "-ftest-coverage":

$ CFLAGS="-fprofile-arcs -ftest-coverage"
./configure && make

$ ./gzip ~/ubuntu-10.10-desktop-i386.iso

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

$ gcov deflate.c
File "deflate.c"
Lines executed:76.98% of 139
deflate.c:creating "deflate.c.gcov"

Полученный в результате файл состоит из трех колонок: количество исполнений
строки, номер строки и сама строка. При этом для строк, не содержащих кода, в
первой колонке будет стоять знак минуса, а для строк, ни разу не выполненных -
последовательность шарпов: #####.

Google Performance Tools

Google Performance Tools (сокращенно GPT) - это разработка сотрудников Google,
предназначенная для поиска утечек памяти и узких мест приложений. Как и gprof,
GPT не является внешней по отношению к тестируемому приложению программой и
заставляет его самостоятельно вести статистику своего исполнения. Однако
используется для этого не внедренный на этапе сборки приложения код, а
библиотеки, которые могут быть прилинкованы к приложению во время сборки или
подключены при запуске.

Всего разработчикам доступно две подключаемых библиотеки: tcmalloc (которая,
по уверению авторов GPT, представляет собой самую быструю на свете реализацию
функции malloc, а также позволяет производить анализ того, как память
расходуется, выделяется и течет) и profiler, генерирующая отчет о выполнении
программы, наподобие gprof. Также в комплект входит утилита pprof,
предназначенная для анализа и визуализации накопленных данных.

Исходный код, а также rpm- и deb-пакеты всего этого набора доступны на
официальной страничке (code.google.com/p/google-perftools), однако я бы не
советовал заморачиваться с ручной установкой, так как набор доступен в
стандартных репозиториях Fedora и Ubuntu, и его можно установить одной простой
командой:

$ sudo apt-get install google-perftools \libgoogle-perftools0
libgoogle-perftools-dev

$ LD_PRELOAD=/usr/lib/libprofiler.so.0.0.0 \
CPUPROFILE=gzip-profile.log ./gzip \
/home/j1m/ubuntu-10.10-desktop-i386.iso

Однако сами гугловцы не советуют применять этот метод (очевидно из-за проблем
с программами, написанными на C++), рекомендуя линковать библиотеку во время
сборки. Что ж, не будем спорить.

Для экспериментов возьмем все тот же gzip и повторно пересоберем его,
слинковав бинарник с нужной библиотекой:

$ cd ~/gzip-1.3.3
$ make clean
$ ./configure
$ LDFLAGS="-lprofiler" ./configure && make

Теперь gzip вновь готов вести лог своего исполнения, но не будет делать этого
по умолчанию. Чтобы активировать профайлер, необходимо объявить переменную
окружения CPUPFOFILE и присвоить ей путь до файла профиля:

$ CPUPROFILE=gzip-cpu-profile.log ./gzip \
~/ubuntu-10.10-desktop-i386.iso
PROFILE: interrupts/evictions/bytes = 4696/946/91976

Как и в случае с gprof, получившийся отчет имеет бинарную форму и может быть
прочитан только с использованием специальной утилиты. В GPT ее роль выполняет
perl-скрипт pprof (в Ubuntu во избежание путаницы с другой одноименной утилитой
он переименован в google-pprof), который может генерировать не только таблицы и
аннотированные исходники на манер gcov, но и визуальные графы вызовов. Всего
существует 11 типов вывода этой утилиты, за каждым из которых закреплен
соответствующий аргумент командной строки:

1. Текстовый (--text) - таблица, подобная выводу gprof;
2. Callgrind (--callgrind) - вывод в формате, совместимом с утилитой kcachegrind (из пакета valgrind);
3. Графический (--gv) - граф вызовов, немедленно отображаемый на экране;
4. Листинг (--list=) - аннотированный листинг указанной функции;
5. Дизассемблированный листинг (--disasm=) - аннотированный
   дизассемблированный листинг указанной функции;
6. Символьный (--symbols) - листинг декодированных символьных имен;
7. Графический файл (--dot, --ps, --pdf, --gif) - граф вызовов, сохраняемый
   в файл;
8. Сырой (--raw) - подготовка бинарного файла профиля к передаче по сети
   (перекодируется с помощью печатаемых символов).

Наибольший интерес для нас представляют текстовый ("--text") и графический
("--gv") типы вызовов. Только они могут дать полную информацию о выполнении
приложения и всех его проблемных местах. Текстовый вывод генерируется следующим
образом:

$ google-pprof --text ./gzip gzip-cpu-profile.log

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

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

Во всем остальном таблица сильно напоминает вывод gprof: по функции на
строку, по показателю на столбец. Всего столбцов шесть:

1. Количество проверок для данной функции;
2. Процент проверок на все остальные функции программы;
3. Количество проверок для данной функции и всех ее потомков;
4. То же число в процентах от общего количества проверок;
5. Имя функции.

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

Несомненным достоинством GPT перед gprof является умение представлять
информацию в графическом виде. Для активации этой функции pprof следует
запускать с флагом "--gv" (кстати, для показа графа будет использована
одноименная утилита):

$ google-pprof --gv ./gzip gzip-cpu-profile.log

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

Еще одно достоинство GPT заключается в способности использовать разные уровни
детализации для вывода данных, позволяя пользователю самому выбирать единицы
дробления. По умолчанию в качестве такой единицы используется функция, поэтому
любой вывод pprof логически разделен на функции. Однако при желании в качестве
единицы дробления можно использовать строки исходного кода (аргумент "--lines"),
файлы ("--files") или даже физические адреса памяти ("--addresses"). Благодаря
такой функциональности GPT очень удобно использовать для поиска узких мест в
больших приложениях, когда сначала ты анализируешь производительность на уровне
отдельных файлов, затем переходишь к функциям и, наконец, находишь проблемное
место на уровне исходного кода или адресов памяти.

И последнее. Как я уже говорил выше, GPT - это не только хороший профайлер,
но и инструмент для поиска утечек памяти, поэтому у него есть один очень
приятный побочный эффект в виде способности к анализу потребления памяти
приложением. Для этого приложение должно быть собрано или запущено с поддержкой
библиотеки tcmalloc, а в переменную HEAPPROFILE записан адрес для размещения
профильного файла. Например:

$ LD_PRELOAD=/usr/lib/libtcmalloc.so.0.0.0 \
HEAPPROFILE=gzip-heap-profile.log \
./gzip ~/ubuntu-10.10-desktop-i386.iso
Starting tracking the heap
Dumping heap profile to gzip-heap-profile.log.0001.heap (Exiting)

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

При необходимости эту информацию можно получить в графическом виде, а также
изменить единицы дробления. Библиотека может быть настроена с помощью различных
переменных окружения, наиболее полезная из которых носит имя HEAP_PROFILE_MMAP.
Она включает профилирование для системного вызова mmap (по умолчанию GPT
собирает статистику только для вызовов malloc, calloc, realloc и new).

Пара слов о Valgrind

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

1. Cachegrind - позволяет собирать статистику по попаданию данных и
   инструкций программы в кэш первого и второго уровней процессора (мощный и
   сложный инструмент, который полезен при выполнении профилирования
   низкоуровневого кода).
2. Massif - профайлер кучи, схожий по функциональности с аналогом из пакета GPT.
3. Callgrind - профайлер, во многом похожий на таковой в gprof и GPT.

По умолчанию в качестве основного плагина Valgrind использует memcheck
(отладчик памяти), поэтому для его запуска в режиме профилирования необходимо
указать нужный плагин вручную. Например:

$ valgrind --tool=callgrind ./program

После этого в текущем каталоге будет создан файл с именем
callgrind.out.PID-программы, который можно проанализировать с помощью утилиты
callgrind_annotate или графической программы kcachegrind (устанавливается
отдельно). Я не буду расписывать формат генерируемых этими программами данных
(он хорошо представлен в одноименных man-страницах), скажу лишь, что
callgrind_annotate лучше запускать с флагом "--auto", чтобы он смог
самостоятельно найти файлы исходных текстов программы.

Для анализа расхода памяти Valgrind следует запускать с аргументом "--tool=massif".
После чего в текущем каталоге появится файл massif.out.PID-программы, который
может быть проанализирован с помощью утилиты ms_print. В отличие от pprof, она
умеет выводить данные не только в виде стандартной таблицы, но и генерировать
красивые ascii-art графики.

Выводы

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

INFO

По умолчанию gprof не выводит профильной информации для функций
библиотеки libc, но ситуацию можно исправить, установив пакет libc6-prof и
собрав тестируемое с библиотекой libc_p: "export LD_FLAGS="-lc_p"".

Активировать профайлер GPT можно не только с помощью переменной окружения
CPUPROFILE, но и обрамив тестируемый участок кода функциями ProfilerStart()
и ProfilerStop(), которые объявлены в google/profiler.h.

WARNING

Из-за требований к безопасности GPT не сработает в отношении приложений с
установленным битом SUID.

Пример описания бизнес-процесса

Простой пример «бизнес-процесса» - приготовление бутерброда для завтрака. При выполнении описания процесса есть небольшие тонкости, которые желательно соблюдать. Познакомьтесь с описанием процесса приготовления бутерброда:

1. Приготовить компоненты;

2. Отрезать кусок батона ножом;

3. Намазать масло на кусок батона.

Описание строится из отдельных операций. Каждая операция заканчивается определенным продуктом (см. табл. 3 )

Таблица 3 - Пример описания бизнес-процесса

Требования к описанию процесса:

1. Описание процесса должно быть полным и кратким. Оно не должно быть слишком детальным, подробным. Так, например, не нужно включать в описание процесса действия типа «взять в руку нож», «отделить часть масла ножом».

2. Описание процесса должно быть последовательным, без пропусков важных элементов. Последовательность операций можно построить и проконтролировать с помощью вопроса «зачем?»

Например: «Приготовить компоненты» зачем? Чтобы «Отрезать кусок батона»

Зачем «Отрезать кусок батона»? Чтобы «Намазать масло на кусок батона».

3. Описание каждой операции процесса начинается с глагола в неопределенной форме «Приготовить…», «Отрезать…», «Намазать…».

Допускается использовать третью форму глагола: приготовляет, отрезает, намазывает.

По утверждению Г.С. Альтшуллера: «Узкое место» - это рабочее место, операция (функция, задача), иногда специалист, где требуются дополнительные затраты времени, усилий, финансов, материальных ресурсов. Особенность узкого места – его ощущают как неудобство, но мало кто задумывается над тем – какова причина, почему оно существует? Обнаружив такое место, можно сформулировать проблему, но более выгодно формулировать противоречие, как признак наличия будущего «сильного и красивого решения».

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

Рисунок 25 - Группы бизнес-процессов

К группе основных относят следующие бизнес-процессы:

1) процессы, создающие добавленную стоимость продукту, который производит компания;

2) процессы, создающие продукт, представляющий ценность для внешнего клиента;

3) процессы, прямой целью которых является получение доходов;

4) процессы, за которые внешний клиент готов платить деньги.

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

Таблица 4 - Характеристики основных бизнес-процессов

Пример основных процессов верхнего уровня для компании, производящей и продающей одежду и обувь представлен на рис.3 Материалы для производства одежды и обуви используются одни и те же - кожа, ткани и т. д. Поэтому процесс «закупка материалов» будет единым для одежды и обуви: ведь закупается некоторое количество материалов, а потом они сортируются на производство одежды и обуви.

Рисунок 26 - Пример основных процессов верхнего уровня для компании, производящей одежду и обувь

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

К обеспечивающим процессам относятся:

процессы, клиентами которых являются основные процессы, структурные подразделения и сотрудники организации;

процессы, которые поддерживают инфраструктуру организации.

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

Таблица 5 - Характеристики обеспечивающих бизнес-процессов

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

К группе управленческих относят следующие бизнес-процессы:

1) процессы, которые обеспечивают выживание, конкурентоспособность и развитие организации и регулируют ее текущую деятельность;

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

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

Таблица 7 - Характеристики бизнес-процессов управления

Рисунок 27 - Типовая структура бизнес-процессов управления

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

Последняя группа бизнес-процессов, которую осталось рассмотреть, – это бизнес- процессы развития.

Бизнес-процессы развития представляют инвестиционные виды деятельности, где усилия прикладываются сегодня, а результаты получаются по прошествии определенного периода. Что такое проект? Проект - это процесс, который реализуется один раз, после чего он завершает свое существование. Ему на смену приходит новый проект, и эта ситуация повторяется многократно.

Таблица 8. Характеристики бизнес-процессов развития

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

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

• Пути повышения экономической эффективности производства: три полезных совета

Наглядный пример: если завод за месяц делает 1000 корпусов для холодильников и 100 дверей, то его конечный результат - всего-навсего 100 готовых холодильников. Значит, «узким местом» является выпуск дверей, поскольку без их нужного количества в течение месяца 900 корпусов будут бесполезными. Следовательно, бессмысленно наращивать объемы и мощности на участках производства корпусов - результативность завода повысится только при увеличении выпуска дверей.

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

«5 фокусирующих шагов ТОС»

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

Шаг 1. Найти основное ограничение - «узкое место»

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

Шаг 2. Решить, как использовать ограничение с максимальной на данный момент отдачей

На этом этапе надо придумать, как исправить положение, чтобы слабое звено заработало на 100%. Может быть, необходимо изменить существующий процесс производства, или внести коррективы в алгоритм общения с клиентами, или установить новые правила работы на слабом участке и т.д.

Шаг 3. Привести все остальные рабочие процессы в соответствие с установленным ограничением

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

«Барабан» - это «узкое место», проблемный участок, задающий темп работы всей компании.

«Буфер» - определенное количество запасов, которое позволит не допускать ни длительного простоя, ни накапливания излишков. Буферные запасы необходимо тщательно планировать и контролировать. Для контроля используется «веревка».

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

Шаг 4. Увеличить мощность ограничения

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

Шаг 5. Вернуться к шагу 1.

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

Как это работает: ТОС на производстве

Возможности применения ТОС на производстве иллюстрирует реальный пример из практики российских компаний.

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

Внедрение ТОС на «Полюсе» началось с поиска ограничений. Поскольку завод не мог обеспечить изготовление того количества холодильников, которое требовалось для выполнения всех заказов, основным ограничением, или «узким местом», являлось производство.

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

Шаг 2. Поиск решения для использования «узкого места» с максимальной отдачей. На «Полюсе» было решено заготавливать корпуса холодильников с вечера и завозить их на конвейер до запуска. Таким образом, к началу работы сборочных бригад у последних все было под рукой. Реализация данной меры потребовала, чтобы примерно десять человек работали дополнительный час вечером и утром. Но связанные с этим дополнительные расходы на оплату труда оказались значительно меньше, чем вложения в приобретение нового заливочного оборудования, не требующего разогрева. Дополнительно был установлен жесткий временной контроль и введено правило, согласно которому сотрудники бригады могли уходить на обед не одновременно, а группами.

Шаг 3. Оптимизация работы «узкого места» (приведение остальных элементов системы в соответствие с ним). Оптимизировать работу сборочного конвейера удалось за счет его частичной разгрузки. Было принято решение некоторые детали собирать в другом цехе и привозить на конвейер уже готовыми. Это позволило сэкономить дополнительное время на сборку и увеличить ежедневный выпуск готовых холодильников.

Шаг 4. Расширение мощности, инвестиции в «узкое место».

На «Полюсе» было внедрено новое оборудование - пробивная машина с программным управлением, которая отличается высокоскоростным режимом работы и способностью обрабатывать заготовки с точностью, приближенной к идеальной. Ее использование позволило увеличить скорость и качество обработки деталей, что соответственно повысило пропускную способность конвейера. В результате общая производительность завода выросла сначала на 40%, а затем - на 70%. Повысить производительность на дополнительные 30% удалось за счет того, что было решено вместо шкафов-боттлеров для хранения напитков производить обычные холодильники. Хотя шкафы-боттлеры приносят вдвое больше прибыли, заготовки для них обрабатываются на пробивной машине в 20 раз дольше, чем заготовки для обычного холодильника. Таким образом, на обычных холодильниках компания в сумме зарабатывала в 10 раз больше, чем на боттлерах.

Шаг 5. Поиск следующего «узкого места» и дальнейшее улучшение всей системы. После увеличения мощности производства ограничением стал недостаточный объем продаж, так как теперь завод не просто выполнял все заказы, но изготавливал даже больше изделий, чем было востребовано покупателями. Справиться с рыночным ограничением также удалось с помощью метода «пяти шагов» за счет того, что была усовершенствована цепочка поставок, и «Полаир» стал предлагать дистрибьюторам более выгодные условия, чем предлагали другие производители.

Результаты внедрения ТОС: всего за два с небольшим года «Полюсу» благодаря ТОС удалось нарастить выпуск холодильных шкафов вчетверо (до 60 000 штук в год), выручку - с $20 млн до $70 млн при одновременном снижении запасов примерно в пять раз и сокращении срока поставок с двух месяцев до недели.