Исаенко П.В., Исаенко А.В. Основы работоспособности технических систем
- формат pdf
- размер 7,50 МБ
- добавлен 30 июля 2015 г.
Учебное пособие с грифом УМО в 2 ч. — Томск: ТГАСУ, 2014. — 324 с.
В книге пособии изложены основы обеспечения работоспособности
сложных технических систем (автомобильный транспорт, средства
обслуживания) в процессе их эксплуатации. Рассмотрены
закономерности изменения технического состояния автомобилей, методы
оценки их эксплуатационной надежности, система и нормативы
технического обслуживания и ремонта в автомобильной отрасли,
включая организацию работы фирменных сервисных систем, методы
анализа производительности и пропускной способности средств
обслуживания.
Приведены примеры решения тематических задач.
Содержание
Термины и понятия, условные сокращения
Часть I. Основы работоспособности технических систем. Состояние и причины её снижения в ходе эксплуатации
Технические системы. Понятие и состояние
Стратегия развития автомобилестроения в России
Жизненный цикл ТС
Факторы снижения работоспособности технических систем
Понятие о качестве и работоспособности изделия
Зависимость технико-эксплуатационных свойств ТС от показателей качества
Критерии технического состояния ТС
Основные причины изменения работоспособного состояния ТС
Влияние условий эксплуатации на работоспособность ТС
Методы оценки работоспособности технических систем
Предмет и методология статистики транспорта
Общие сведения о математической статистике
Планы (стратегии) испытаний и типы выборки
Классификация закономерностей изменения технического состояния изделий ТС
Закономерности случайных процессов изменения технического состояния ТС (закономерность второго вида)
Понятие о процессе восстановления (закономерность третьего вида)
Надежность технических систем
Надежность как комплексный показатель качества и работоспособности изделия
Свойства и показатели надежности
Показатели надежности неремонтируемых изделий
Показатели надежности ремонтируемых изделий
Нормирование показателей надежности ТС
Методы расчета вероятностной оценки надежности ТС и их агрегатов
Основы управления техническими системами. Обеспечение их
работоспособности в эксплуатацииМетоды определения нормативов технического обслуживания при технической эксплуатации машин и оборудования
Понятие о нормативе
Методы определения периодичности ТО
Трудоемкость ТО и Р
Способы определения потребностей в запасных частях
Определение норм расхода запасных частей
Технологические процессы обеспечения работоспособности технических систем
Автосервис как сфера услуг
Сервис и техническая эксплуатация – подсистемы комплекса транспортных и транспортно-технологических машин и оборудования
Проблемы, состояние и перспективы развития автосервиса в России
Планово-предупредительная система ТО и Р
Методы управления работоспособностью технических систем
Понятие об управлении и информации
Организация и управление производством работ по ТО и ТР подвижного состава на АТП
Методы принятия решений при управлении ТС
Марковские случайные процессы, цепи и последовательности
Основы теории массового обслуживания
Диагностика как метод управления работоспособностью ТС
Прогнозирование технического состояния ТС как элемент управления их работоспособностью
Пути повышения работоспособности технических систем
Обеспечение минимальной трудоемкости ТО и Р ТС
Общие тенденции повышения работоспособности деталей машин
Обеспечение работоспособности автомобилей
Обеспечение работоспособности сельскохозяйственных машин
Безопасность технических систем
Нормативные показатели безопасности ТС
Методы повышения безопасности ТС и технологических процессов
Экологическая безопасность ТС
Заключение
Список рекомендуемой литературы
Приложения
Поиск материала «Основы работоспособности технических систем, Зорин В.
А., 2009» для чтения, скачивания и покупкиНиже показаны результаты поиска поисковой системы Яндекс. В результатах могут быть показаны как эта книга, так и похожие на нее по названию или автору.
Search results:
- Зорин В. А. З-862 Основы работоспособности технических…
Зорин В. А. З-862 Основы работоспособности технических систем : учеб-. ник для студ. высш. учеб. заведений / В. А. Зорин. — М. : Издательский центр «Академия», 2009. — 208 с. ISBN 978-5-7695-6003-3. Рассмотрены основные процессы, вызывающие снижение работоспо-собности технических систем (машин): трение, изнашивание, пластичес-кое деформирование, усталостное и коррозионное разрушение деталей машин. Приведены основные направления и методы обеспечения рабо-тоспособности машин.
k571.ucoz.org
- Зорин В.А. Основы работоспособности технических систем
Приведены основные направления и методы обеспечения работоспособности машин.
Методическое пособие по дисциплинам «Основы работоспособности технических систем», «Техническая эксплуатация автомобилей», «Основы теории надежности и диагностики» для студ. спец. 190603 «Сервис транспортных и технологических машин и оборудования», 190601 «Автомобили и автомобильное хозяйство» всех форм обучения.
www.studmed.ru
-
Купить эту книгу
- Канцтовары
Канцтовары: бумага, ручки, карандаши, тетради. Ранцы, рюкзаки, сумки. И многое другое.
my-shop.ru
- Основы надежности и работоспособности технических систем
5. Классификация отказов. 6. Сбор и обработка информации об отказах. 7. Влияние трения и смазочных материалов на работоспособность техни-ческих систем.
8. Усталость материалов элементов машин. 9. Элементы теории надежности технических систем. 10. Законы, отражающие изменение и прекращение работоспособности технических систем. 11. Методы оценки измерительной информации 12. Моделирование измерительной информации, получаемой при оценке работоспособности технических систем.vk.com
- Зорин В.А. Основы работоспособности технических систем
Методическое пособие по дисциплинам «Основы работоспособности технических систем», «Техническая эксплуатация автомобилей», «Основы теории надежности и диагностики» для студ. спец. 190603 «Сервис транспортных и технологических машин и оборудования», 190601 «Автомобили и автомобильное хозяйство» всех форм обучения.
Приведены основные направления и методы обеспечения работоспособности машин. Описаны методы оценки работоспособности элементов и технических систем в целом. Для студентов высших.
www.studmed.ru
- Основы работоспособности технических систем | Зорин…
В учебнике рассмотрены основные процессы, вызывающие снижение работоспособности машин: трение и изнашивание, коррозия, усталость и старение материалов, а также методы управления этими процессами. Большое внимание уделено основам триботехники – научной дисциплине, изучающей трение, изнашивание и процессы смазывания элементов машин. Скриншоты страниц. Скачать книгу бесплатно (djvu, 22.96 Mb) | Читать «Основы работоспособности технических систем».
bookscat.org
- Зорин В.А. Основы работоспособности технических систем
Приведены основные направления и методы обеспечения работоспособности машин. Описаны методы оценки работоспособности элементов и технических систем в целом.
Для студентов высших учебных заведений. Может быть полезен специалистам по сервису и технической эксплуатации автомобилей, тракторов, строительных, дорожных и коммунальных машин.Ч 1. Основы теории: Учеб. пособие для студентов технических специальностей вузов / Под общ. ред. Е. В. Сугака. – Красноярск: Сибирский государственный технологический университет, 1998.
eruditor.io
- Основы работоспособности технических систем | Зорин…
В учебнике рассмотрены основные процессы, вызывающие снижение работоспособности машин: трение и изнашивание, коррозия, усталость и старение материалов, а также методы управления этими процессами. Большое внимание уделено основам триботехники – научной дисциплине, изучающей трение, изнашивание и процессы смазывания элементов машин. Скриншоты страниц. Скачати (djvu, 22.96 Mb) | Читати «Основы работоспособности технических систем».
ua.booksee.org
- Основы работоспособности технических систем: учебник
Основы работоспособности технических систем: учебник | В. А. Зорин | download | Z-Library. Download books for free. Find books…
1lib.net
- Зорин В.А. Основы работоспособности технических систем…
Выберите тип работы Часть диплома Дипломная работа Курсовая работа Контрольная работа Решение задач Реферат Научно – исследовательская работа Отчет по практике Ответы на билеты Тест/экзамен online Монография Эссе Доклад Компьютерный набор текста Компьютерный чертеж Рецензия Перевод Репетитор Бизнес-план Конспекты Проверка качества Экзамен на сайте Аспирантский реферат Магистерская работа Научная статья Научный труд Техническая редакция текста Чертеж от руки Диаграммы, таблицы Презентация к.
nashaucheba.ru
- Озорнин С.П. Основы работоспособности технических систем…
Повышение эффективности технических систем различного назначе-ния способствует ускоренному прогрессу техники и технологии в разнооб-разных сферах их применения. Используемые технические системы доста-точно сложны по своей конструкции, показатели эксплуатационного фона весьма разнообразны и имеют случайный характер. В связи с этим, обеспе-чение работоспособности технических систем, их безопасной и эффективной эксплуатации становится все более значимым.
zabgu.ru
- Зорин В.А. Основы работоспособности технических систем…
n1.djvu. Скачайте архив чтобы просмотреть данный файл.
nashaucheba.ru
- Зорин В.А. Основы работоспособности технических систем
Учебник для вузов.
— М. : Издательский центр «Академия», 2009. — 208 с.Рассмотрены основные процессы, вызывающие снижение работоспособности технических систем (машин): трение, изнашивание, пластическое деформирование, усталостное и коррозионное разрушение деталей машин.Гайкович А.И. Основы теории проектирования сложных технических систем (Документ). Тарасик В.П. Математическое моделирование технических систем. Учебник для вузов (Документ). Костерев В.В. Надежность технических систем и управление риском…
nashaucheba.ru
- Основы работоспособности технических систем | Зорин…
Топ Z-Librarians. Блог. Главная Основы работоспособности технических систем.
Насколько вам понравилась эта книга? Какого качества скаченный файл? Скачайте книгу, чтобы оценить ее качество.
ru.1lib.education
- Зорин В.А. Основы работоспособности технических систем
Учебник для студ.
высш. учеб. заведений. – М.: Издательский центр «Академия», 2009. – 208 с.Рассмотрены основные процессы, вызывающие снижение работоспособности машин: трение, изнашивание, пластическое деформирование, усталостное и коррозионное разрушение деталей машин.Гайкович А.И. Основы теории проектирования сложных технических систем (Документ). Тарасик В.П. Математическое моделирование технических систем. Учебник для вузов (Документ). Костерев В.В. Надежность технических систем и управление риском…
nashaucheba.ru
- Зорин В.А. Основы работоспособности технических систем
Учебник для ВУЗов. – М.: Магистр-Пресс, 2005. – 536 с.Обеспечение высокого уровня работоспособности машин является важнейшей проблемой машиностроения.
Гайкович А.И. Основы теории проектирования сложных технических систем (Документ). Тарасик В.П. Математическое моделирование технических систем.
Учебник для вузов (Документ). Костерев В.В. Надежность технических систем и управление риском (Документ).nashaucheba.ru
- Зорин В.А. Основы работоспособности технических систем…
n1.djvu. Скачайте архив чтобы просмотреть данный файл.
nashaucheba.ru
- «Основы работоспособности технических систем» — читать…
Основы работоспособности технических систем. Учебник. Допущено У МО вузов РФ по образованию в области транспортных машин и транспортно-технологических комплексов в качестве учебника для студентов высших учебных заведений, обучающихся по специальностям направления подготовки дипломированных специалистов «Эксплуатация наземного транспорта и транспортного оборудования» и по специальности «Сервис транспортных и технологических машин и оборудования (по отраслям)» ‘.
Znanium.com
- Книга «Основы работоспособности технических систем.»
Вы выбрали книгу «Основы работоспособности технических систем. Учебник (Зорин В.А.)». Вы можете совершенно бесплатно скачать эту книгу, но только для ознакомления и личного, не коммерческого использования. Ссылка на скачивание расположена ниже на странице.
Для начала скачивания выберите сервер и нажмите ссылку «скачать». Основы работоспособности технических систем. Учебник (Зорин В.А.) 23.6 Mb.
read.in.ua
- Основы работоспособности технических систем | Зорин…
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ В.А. ЗОРИН ОСНОВЫ РАБОТОСПОСОБНОСТИ ТЕХНИЧЕСКИХ СИСТЕМ Учебник Допущено У МО вузов РФ по образованию в области транспортных машин и транспортно-техиологических комплексов в качестве учебника для студентов высших учебных заведений, обучающихся по специальностям направления подготовки дипломированных специалистов *Эксшуатация наземного транспорта и транспортного оборудования* и по специальности «Сервис транспортных и технологических.
..b-ok.cc
- Зорин В.А. Основы работоспособности технических систем
Учебник для студ. высш. учеб. заведений. – М.: Издательский центр «Академия», 2009. – 208 с.Рассмотрены основные процессы, вызывающие снижение работоспособности машин: трение, изнашивание, пластическое деформирование, усталостное и коррозионное разрушение деталей машин.
Гайкович А.И. Основы теории проектирования сложных технических систем (Документ). Тарасик В.П. Математическое моделирование технических систем. Учебник для вузов (Документ). Костерев В.В. Надежность технических систем и управление риском…
nashaucheba.ru
- Книга Основы работоспособности технических систем ( Зорин…)
Читать онлайн книгу Основы работоспособности технических систем автора Зорин В.
А.bookree.org
- Книга «Основы работоспособности технических систем.»
Вы выбрали книгу «Основы работоспособности технических систем. Учебник (Зорин В.А.)». Вы можете совершенно бесплатно скачать эту книгу, но только для ознакомления и личного, не коммерческого использования. Ссылка на скачивание расположена ниже на странице.
Для начала скачивания выберите сервер и нажмите ссылку «скачать». Основы работоспособности технических систем. Учебник (Зорин В.А.) 23.6 Mb.
read.in.ua
- Основы работоспособности технических систем | Зорин…
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ В.А. ЗОРИН ОСНОВЫ РАБОТОСПОСОБНОСТИ ТЕХНИЧЕСКИХ СИСТЕМ Учебник Допущено У МО вузов РФ по образованию в области транспортных машин и транспортно-техиологических комплексов в качестве учебника для студентов высших учебных заведений, обучающихся по специальностям направления подготовки дипломированных специалистов *Эксшуатация наземного транспорта и транспортного оборудования* и по специальности «Сервис транспортных и технологических.
..pl.b-ok.cc
- Зорин, Владимир Александрович – Основы работоспособности…
Основы работоспособности технических систем [Текст] : практикум / В. А. Зорин, Н. С. Севрюгина ; М-во образования и науки Российской Федерации, Московский автомобильно-дорожный гос. технический ун-т (МАДИ), Белгородский гос. технологический ун-т им. В. Г. Шухова. – Белгород : Изд-во БГТУ, 2014. – 141 с. : ил., табл.; 21 см.; ISBN 978-5-361-00200-9.
search.rsl.ru
- Основы работоспособности технических систем : учебное О-75…
Для студентов направлений подготовки 35.03.06 -«Агроинженерия», 23.03.03 – «Эксплуатация транспортно-технологических машин и комплексов» изучающих дисциплины «Надежность и ремонт машин», «Основы теории надежности» и «Основы работоспособности технических систем».
Цель учебного пособия «Основы теория надежности в при-мерах и задачах» — помочь читателю изучить теорию надежно-сти и приобрести навыки применения ее результатов к реше-нию различных прикладных вопросов.
Учебное пособие содержит четыре главы.www.StGAU.ru
- Основы работоспособности технических систем…
1 ОСНОВЫ РАБОТОСПОСОБНОСТИ ТЕХНИЧЕСКИХ СИСТЕМ Кандидат технических наук, доцент Пресняков В.А. Каф. СТЭА уч. год. 2 2 Введение В настоящее время в России резко изменились условия взаимоотношений поставщиков и потребителей на рынке товаров и услуг.
8 8 Техническое состояние и работоспособность автомобиля Современный автомобиль состоит из 1518 тыс. деталей, из которых 79 тыс. теряют свои первоначальные свойства при работе, причем около 34 тыс. имеют срок службы меньше, чем автомобиль.
www.myshared.ru
- Зорин, Владимир Александрович – Основы работоспособности…
00 $a Основы работоспособности технических систем : $b учебник для студентов, высших учебных заведений, обучающихся по специальности “Сервис транспортных и технологических машин и оборудования (по отраслям)” направления подготовки “Эксплуатация наземного транспорта и транспортного оборудования” $c В.
Р Темы рефератов по дисциплине «Основы работоспособности технических систем»: 1. Отказы машин и их элементов. Показатели надежности 2. Технический прогресс и надежность машин. История формирования и развития триботехники. Роль триботехники в системе обеспечения долговечности машин. Трибоанализ механических систем 3. Причины изменения технического состояния машин в эксплуатации 4. Взаимодействие рабочих поверхностей деталей. Тепловые процессы сопровождающие трение.dropdoc.ru
- Зорин В. А. – Основы работоспособности технических систем
Автор:Зорин В. А. Год: 2009 Издание:Academia Страниц: 208 ISBN: 9785769560033 Рассмотрены основные процессы, вызывающие снижение работоспособности технических систем (машин): трение, изнашивание, пластическое деформирование, усталостное и коррозионное разрушение деталей машин. Приведены основные направления и методы обеспечения работоспособности машин.
Описаны методы оценки работоспособности элементов и технических систем в целом.spisok-literaturi.ru
- Основы работоспособности технических систем (2-е издание…)
Содержание Предисловие Глава 1. Проблема обеспечения работоспособности технических систем 1.1. Технический прогресс и надежность машин 1.2. История формирования и развития триботехники 1.3. Роль триботехники в системе обеспечения работоспособности машин 1.4. Трибоанализ технических систем 1.5. Причины снижения работоспособности машин в эксплуатации Глава 2. Свойства рабочих поверхностей деталей машин 2.1. Параметры профиля рабочей поверхности детали 2.2.
www.centrmag.ru
- Оценка работоспособности технической системы – Крюков…
Заметим, что чем больше число измеряемых диагностических параметров, тем более полной является информация о состоянии технической системы, но при этом повышается трудоемкость и стоимость диагностирования.
При выборе диагностических параметров необходимо предусмотреть, чтобы они были независимы. Как правило, выбор этих параметров осуществляется на основе накопленного опыта с использованием рекомендации, содержащихся в нормативно-технической документации.nashaucheba.ru
- Крюков В.Г. Основы работоспособности технических систем…
В данном пособии излагается лекционный курс дисциплины “Основы работоспособности технических систем”, читаемой для студентов специальности “Эксплуатация и обслуживание транспортных и технологических машин и оборудования”. Это пособие составлено на базе одноименного курса лекций, который был разработан и читался в течение ряда лет преподавателем кафедры “Прикладной математики” Мелузовым Ю.В., так рано ушедшим от нас.
nashaucheba.ru
На данной странице Вы можете найти лучшие результаты поиска для чтения, скачивания и покупки на интернет сайтах материалов, документов, бумажных и электронных книг и файлов похожих на материал «Основы работоспособности технических систем, Зорин В.
А., 2009»
Для формирования результатов поиска документов использован сервис Яндекс.XML.
Нашлось 20 млн ответов. Показаны первые 32 результата(ов).
Дата генерации страницы:
404 Cтраница не найдена
Размер:
AAA
Изображения Вкл. Выкл.
Обычная версия сайта
К сожалению запрашиваемая страница не найдена.
Но вы можете воспользоваться поиском или картой сайта ниже
|
|
Методическое пособие для выполнения практической работы по дисциплинам «Основы теории надежности и диагностики», «Основы работоспособности технических систем»
Федеральное государственное автономное образовательное учреждение высшего профессионального образования
«СИБИРСКИЙ ФЕДЕРАЛЬНЫЙ УНИВЕРСИТЕТ»
Кафедра «Транспорта»
«ОСНОВЫ ТЕОРИИ НАДЕЖНОСТИ И ДИАГНОСТИКИ»
Методическое пособие для решения научных и
практических задач системы профилактики АТС для
специальностей 190601.
65: ”Автомобили и автомобильное хозяйство”, 190603.65 ”Сервис
транспортных и технологических машин и оборудования (по отраслям)” и направлениям
190600.68 “Эксплуатация транспортно-технологических машин и комплексов”,
190600.62 “Эксплуатация транспортно-технологических машин и комплексов”
Красноярск 2012
УДК 629.113:658.562.3
Б90
Основы теории надежности и диагностики.
Методическое
пособие для выполнения практической работы по дисциплинам «Основы теории
надежности и диагностики, Основы работоспособности технических систем».
Предназначено для подготовки студентов по специальности 190601.65: «Автомобили и
автомобильное хозяйство», 190603.65 «Сервис транспортных и технологических
машин и оборудования (по отраслям)», бакалавров по направлению 190600.62 “Эксплуатация
транспортно-технологических машин и комплексов”, магистров 190600.68 “Эксплуатация
транспортно-технологических машин и комплексов” всех форм обучения
(дневное, заочное), а
также повышение квалификации инженерно-технических работников транспортной
отрасли.
Разработали д.т.н., профессор Н. Ф. Булгаков, ассистент Коваленко В.В., аспирант Курочкин Э.Э., аспирант Шалимов С.Н., ПИ СФУ, 2012, 50..с.
Печатается по разрешению редакционно-издательского совета университета
Сибирский федеральный университет, 2012 г.
Содержание
Введение. 8
1 Модель расчета объема выборки и планирование эксперимента. 10
2 Модель оценивания показателей долговечности ТС.. 13
2.1 Оценка среднего технического ресурса до первой замены элементов ТС (точечная оценка) 13
2.2 Интервальная оценка. 14
2.3 Оценка параметра масштаба закона Вейбулла-Гнеденко. 16
2.4 Проверка нулевой гипотезы.. 16
2.5 Оценка характеристик теории вероятности: плотности вероятности и функции распределения отказов f(L), F(L) 21
3 Модель оценивания количественных характеристик долговечности и безотказности. 23
3.1 Оценка вероятности безотказной работы.. 23
3.2
Определение потребности в запасных частях.
25
3.3 Оценка гамма – процентной наработки до отказа. 26
3.4 Оценка интенсивности отказов. 27
4 Оценка показателей процесса восстановления. 30
4.1 Ведущая функция восстановления. 31
4.2 Параметр потока восстановления. 32
4.3 Графоаналитический метод расчета ведущей функции и параметра потока восстановления. 32
5 Инструкция работе с программой. 39
6 Методические требования к выполнению практической (курсовой) работы.. 44
7 Варианты заданий. 45
Приложение 1. 57
Приложение 2. 58
Приложение 3. 59
Литература. 60
Обозначения
– десятичный логарифм
Const- постоянная величина (константа)
– стремится к …
– бесконечность
– сумма
-сумма, в которой i изменяется от 1 до n
, -обозначения функций, например: , .
Латинский алфавит
Aa-а
Bb-бэ
Cc-цэ
Dd-дэ
Ee-е
Ff-эф
Gg-ге(же)
Hh-ха(аш)
Ii-и
Jj-йот(жи)
Kk-ка
Ll-эль
Mm-эм
Nn-эн
Oo-о
Pp-пэ
Qq-ку
Rr-эр
Ss-эс
Tt-тэ
Uu-у
Vv-вэ
Ww-дубль-вэ
Xx-икс
Yy-игрек
Zz-зэт
Греческий алфавит
– Альфа
-бэта
-гамма
-дельта
-эпсилон
-дзэта
-эта
-тэта
-иота
-каппа
-ламбда
-мю
-ню
-кси
-омикрон
-пи
-ро
-сигма
-тау
-фи
-хи
-ипсилон
-пси
-омега
ЗАДАНИЕ НА ПРАКТИЧЕСКУЮ РАБОТУ
по дисциплине: Основы теории надежности и диагностики
Студент
(а)………………………….
.……Группа …………….
ТЕМА: Модели оценивания показателей надежности и параметров диагностики транспортных средств (ТС) (на примере элементов ТС)
ЦЕЛЬ – повышение уровня надежности и безопасности ТС
Задачи:
– провести анализ научных и прикладных исследований по надежности и диагностики ТС, проводимые в России и за рубежом;
– произвести оценку показателей долговечности и безотказности;
– составить перечень регламентных операций по их номенклатуре, обеспечивающие безопасность;
– определить потребность элементов ТС, влияющие на безопасность по показателям безотказности.
Исходные данные: выборки до I, I, III-замены, тыс. км:
I. 98 101 104 112 115 119 126 135 138 140 145 152 164 174 179 181 195 214 220 237 260 264 269
II. 19 29 31 47 69 89 106 111 127 136 146 147 148 150 153 154 155 161 165 170
III. 41 12 15 17 19 35 39 42 46 58 76 85 44 50 15 18 59
Пояснительная записка оформляется в
соответствии с действующим в университете СТО.
Адреса для консультации по интернету:
[email protected] д.т.н., проф. Н.Ф. Булгаков
Дата выдачи задания 09.09.20
Срок окончания работы 19.12.20
Руководитель работы д.т.н., проф. _________________Н.Ф. Булгаков
(подпись)
Красноярск 20__
С целью увеличения конкурентоспособности транспортных средств (ТС) на мировом рынке, особенно, в период рыночных реформ, выявляются принципиальные изменения в самом характере деятельности инженера. Соответственно предъявляются к его профессиональным знаниям, навыкам, общей эрудиции и новые требования необходимые для создания надежной и современной технологии профилактики ТС, обеспечивающая безопасность на транспорте с использованием средств диагностики.
Профилактика – искусство прогнозирования расчетных значений показателей надежности и параметров диагностики на периодических интервалах технического ресурса ТС, с момента ввода их в эксплуатацию
Эффективный процесс решения проблем для ИТ-специалистов
Как ИТ-специалисты мы регулярно должны устранять всевозможные технологические проблемы по мере их возникновения в повседневной работе.
Это руководство проведет вас через мыслительный процесс и практические шаги, необходимые для эффективного решения проблем.
Иногда проблемы, с которыми мы сталкиваемся, незначительны по своей природе и очень легко решаемы — например, обращение в службу поддержки, когда новый сотрудник не может получить доступ или сохранить файлы на своем домашнем диске (в данном случае, потому что человек, создавший пользователя, но забыл создать и домашний диск!).
Бывают случаи, когда мы боремся с техническими проблемами на противоположном конце спектра, которые чрезвычайно сложны и могут затронуть тысячи и тысячи пользователей. И давайте не забудем упомянуть еще один сценарий, с которым, вероятно, сталкивались все ИТ-специалисты за время своего пребывания в должности, сценарий «Испытание огнем»!
Независимо от того, является ли проблема, с которой вы столкнулись, крупной или мелкой по масштабу, есть одна единственная истина в поиске решения возникшей проблемы… Эффективный процесс решения проблемы и минимизация времени, необходимого для поиска основного корня причиной часто является прямое сочетание фундаментального и технического понимания существующей технологии и способности демонстрировать логическую обработку мыслей в отношении самой проблемы.
Фундаментальное понимание
Это само собой разумеется, но очень важно понимать, как что-то
работает в первую очередь , если вы хотите эффективно устранять неполадки, не отбрасывая случайные и случайные предположения или подходя к проблеме с помощью эквивалент двуствольного ружья.
Автомеханику, например, будет гораздо труднее устранять неполадки, почему двигатель автомобиля не заводится, если он не понимает основных принципов, необходимых для запуска этого двигателя (искра топлива, компрессии). Точно так же ИТ-специалисту будет трудно найти и устранить причину, по которой пользователи на сайте A не могут взаимодействовать с серверами и ресурсами на сайте B, если им не хватает фундаментальных знаний о сети, маршрутизации и способах VPN работают.
Логическая обработка мыслей
Это одна из тех характеристик, которые либо есть у человека, либо его нет. Научить кого-то, как логически пройти через проблему в поисках решения, редко можно чему-то научить.
Сколько раз вы сталкивались с ситуацией в прошлом, когда ваш коллега устранял неполадки в сети или сервере, и просто по случайному наблюдению вы понимали, что они идут по ложному пути и тратят время на изучение чего-то, что не имеет абсолютно никакого отношения к делу. с первопричиной реальной проблемы?
Конечно, нелегко научить кого-то, как логически проходить и обрабатывать, как эффективно устранять проблемы. На самом деле мозг некоторых людей просто не так устроен . Хотя мы не обязательно можем исправить или изменить то, как устроен мозг человека, эта статья может помочь людям, испытывающим затруднения в этой области, предоставив им вопросы, которые стоит задать, чтобы ускорить процесс устранения неполадок и не тратить время на изучение. области, которые не имеют ничего общего с основной проблемой или первопричиной.
Вопросы для эффективного решения проблем
1. Какова реальная проблема?
Это должен быть первый вопрос, который должен задать ИТ-специалист при устранении различных проблем, связанных с ИТ, даже если только для проверки уже предоставленной информации.
Как правило, это будет означать беседу с человеком или группой лиц, которые сообщили о проблеме в первую очередь. Конечно, нередки случаи, когда сообщаемая проблема запутывается или искажается при обращении к нескольким людям или каналам до того, как вы впервые услышите о ней.
Люди часто перефразируют, когда диктуют то, что кто-то ранее сказал, поэтому вполне возможно, что первоначальная жалоба превратится во что-то совершенно другое, когда она будет передаваться через разных людей:
Мы все сталкивались с такими сценариями в прошлом и они могут сильно разочаровывать, тем более, когда проблемы гораздо важнее, чем способность одного сотрудника добавлять товары в свою корзину покупок на Amazon.
Дело в том, что не принимай как должное то, что тебе говорят . Потратьте время, необходимое для того, чтобы убедиться, что то, о чем вам сообщают, действительно происходит и является первоначальной причиной, по которой проблема была поднята в первую очередь.
Кроме того, уделив время разговору с источником, в данном случае с Мэри, вы сможете задать важные уточняющие вопросы, которые могут дополнительно помочь в диагностике проблемы по мере того, как о ней сообщается.
2. У кого возникла проблема?
Без знания того, кто испытывает проблему, ваша способность сосредоточить свои усилия по устранению неполадок в конкретной области будет уменьшена, и вы можете уйти в направлении, которое даже не нужно или даже отдаленно не связано с источником проблемы. Один из вопросов, который следует задать, заключается в том, кто именно сталкивается с проблемой?
Это (например):
- Один пользователь
- Группа/отдел пользователей
- Весь удаленный филиал
- Весь главный офис – и удаленные филиалы
Каждая организация отличается тем, что относится к «Кто», но есть существенные различия в следующем сценарии и в том, что может быть основной проблемой, связанной с IP-телефонами компании, когда ИТ-специалист, вызванный для решения проблемы, имеет более четкое представление.
понимание того, «Кто» на самом деле затронут:
Суть в том, что когда ИТ-специалист начинает понимать, «Кто» действительно затронут , он может избавиться от необходимости перемещаться по ненужным путям при устранении неполадок и вместо этого может работать над сужением своих усилий по устранению неполадок до более конкретного и краткого область. В случае с одним пользователем выше, зачем тратить время на устранение неполадок VPN-туннеля, если проблема касается только Джерри? Вот почему знать «Кто» чрезвычайно важно.
Вот еще один пример того, что время от времени слышит ИТ-специалист или инженер по беспроводной связи. «Помогите! Беспроводная связь полностью отключена во всем здании. Все сообщают о проблемах» . В таких ситуациях сделайте себе одолжение и обратите особое внимание на такие слова или фразы, как «полностью», «все» и «полностью вниз», когда сообщается о проблемах. Эти «всеохватывающие» фразеологии, как правило, преувеличивают то, что происходит на самом деле, и могут ввести вас в заблуждение.
Нередко при исследовании проблемы ИТ-специалист или инженер по беспроводной связи быстро узнает, что «все» здание, или «все», или что беспроводная сеть «полностью не работает» (что, например, в школе , может повлиять на 3000+ пользователей) оказывается, что единственная беспроводная точка доступа не работает в одном небольшом офисе, что влияет на 5 реальных пользователей (а не на 3000+ пользователей, как, кажется, подразумевают «все»).
Имейте в виду, что проблемы иногда могут быть преувеличены и преувеличены , особенно когда пользователь или группа пользователей регулярно разочаровываются в технологиях или связаны с ними (любой ИТ-специалист, вероятно, сталкивался с такими требовательными пользователями, которые плачут из-за чего угодно!).
Ничего не предполагай!
Потратьте время, чтобы проверить, кто действительно испытывает проблему, и уделите время, необходимое для ПРОВЕРКИ представленной вам информации.3. Когда возникла проблема?
Знание того, когда на самом деле возникла проблема (с учетом конечных деталей, таких как точный день и точное время), часто может обеспечить лучшее понимание проблемы и помогают инициировать более определенные идеи и потенциальные решения , связанные с основной причиной, которую должен решить данный ИТ-специалист.
Представьте себе, что вы привели нового клиента для решения критических проблем с его интернет-сервисами и сказали:
«Интернет-труба — это проблема. Люди случайным образом наблюдают скачки производительности и странные проблемы при просмотре веб-страниц, и мы не знаем, почему».
Менее опытный ИТ-специалист может с головой погрузиться в журналы брандмауэра, мониторинг полосы пропускания, открыть заявку на устранение неполадок непосредственно у интернет-провайдера и попытаться выяснить, что происходит, но кто-то с большим опытом сначала сделает паузу, чтобы задать дополнительные вопросы , желая получить более подробную информацию о том, «когда» возникла проблема.
- Это ВСЕГДА было проблемой?
- КОГДА впервые появились сообщения об этих случайных проблемах с просмотром Интернета?
Знание «когда» дает ИТ-специалисту более точную информацию, которую он может использовать при попытке выяснить, что на самом деле происходит.
Если ответ на приведенные выше вопросы возвращается как, «Первое сообщение о проблеме пришло 10 дней назад». Это МОЖЕТ дать некоторое дополнительное представление о том, что следует изучить дальше.
Конечно, просмотр журналов брандмауэра и показателей использования полосы пропускания за последние 2 недели имеет смысл, зная, что проблема проявилась в течение последних 10 дней, но вряд ли стоит тратить много времени на просмотр журналов и показателей использования полосы пропускания за последние 3 недели. + месяцев назад. При этом еще раз попробуйте ПОДТВЕРДИТЬ информацию, которую вам сообщают . Возможно, человек, дающий вам ответ, смутно помнит, что это было 10 дней назад, но на самом деле прошло всего 3 дня!
В этой конкретной ситуации, когда Интернет сообщается как спорадический, вполне возможно, что примерно 11 дней назад другой компьютерный специалист на месте решил включить функцию UTM (унифицированное управление угрозами) в своем брандмауэре, чтобы обеспечить дополнительную антивирусную проверку.
, IDS (службы обнаружения вторжений), гео-IP-фильтрация и множество других полезных функций, обычно включаемых в наборы функций UTM.
К сожалению, как прямой результат, процессоры/ЦП брандмауэра стали перегруженными и не могут пропускать трафик достаточно быстро, чтобы соответствовать дополнительным требованиям к обработке, требуемым при включенном наборе функций UTM брандмауэра.
Важно «когда»!
Всегда знать «Когда» возникла проблема (насколько это помнит каждый) — это то, что стоит выяснить.4. Проблема периодическая или постоянная?
Еще одним ключевым элементом эффективного процесса решения проблем является выяснение того, возникает ли сообщаемая проблема постоянно или только время от времени? Проблемы, которые константа или фиксированная , как правило (хотя и не всегда) проще для устранения неполадок . В то время как проблемы, которые являются периодическими и кажущимися случайными, обычно сложнее устранить.
Сколько раз нас, ИТ-специалистов, вызывали для устранения проблемы только для того, чтобы обнаружить, что по прибытии проблема внезапно исчезла, но никто не сделал ничего конкретного для ее решения!? Такие ситуации могут сильно разочаровать не только ИТ-специалиста, но и конечного пользователя, потому что вероятность повторного появления проблемы довольно высока (и, скорее всего, снова появится через несколько коротких мгновений после ухода ИТ-специалиста!)
Лучшее, что можно сделать в этих сценариях, это документ КОГДА возникла проблема и как ДОЛГО она продолжалась до того, как она чудесным образом «исправилась сама», так что в следующий раз, когда появится та же самая проблема, вы сможете собрать воедино некоторые грубые и основные предположения или теории, основанные на том, КОГДА это происходило ранее и как ДОЛГО это длилось каждый раз.
Беспроводной хаос только в обеденное время?!
Даже при периодически возникающих проблемах при наличии достаточного количества времени ИТ-специалист может собрать достаточно информации, чтобы собрать воедино и понять, что «проблема с беспроводной сетью» , как сообщает бухгалтерия, обычно возникает только около полудня и длится до 30 минут или около того.
Как оказалось, есть вероятность, что ближайшая беспроводная точка доступа для бухгалтерии находится в ближайшей комнате отдыха/обеда. Что еще есть в этой комнате для отдыха/обеда, кроме беспроводной точки доступа (и ужасного запаха кофе)? Дин! Ты угадал! Микроволновая печь для людей, чтобы разогреть их обеденные блюда, которые, когда микроволновая печь работает и нагревает остатки вчерашнего ужина со спагетти, приводит к тому, что весь беспроводной спектр 2,4 ГГц, на котором работает точка доступа, выходит из строя и лишает возможности стабильной работы. беспроводная производительность.
5. Что недавно изменилось?
Это один из вопросов, который, к сожалению, задают недостаточно часто, просто игнорируют, а в других случаях просто полностью игнорируют (позор вам, если вы попадаете в эту категорию!). Технологии — очень обидчивый и сверхчувствительный зверь , и чаще всего не слишком любезно вносят изменения. Даже изменения, которые должны решить или предотвратить другие известные проблемы, часто приводят к возникновению новых и неожиданных проблем.
Нередко иногда даже плановое техническое обслуживание оборудования может вызвать проблемы .
Сценарий 1
Возьмем, к примеру, обновление прошивки на сетевом коммутаторе . Это должна быть относительно беспроблемная рутинная операция, но внезапно пользователи сообщают, что у них иногда возникают проблемы со входом в систему. Это происходит с более чем одним пользователем, на самом деле, об этом время от времени сообщают по всему зданию в ранние утренние часы, когда большинство сотрудников прибывают к началу своей смены.
«Что изменилось» недавно? На выходных вы решили обновить прошивку на своих пограничных коммутаторах, и теперь безопасность портов, настроенная на коммутаторах с использованием аутентификации AAA с помощью Radius, работает не так, как ожидалось. К сожалению, похоже, что новое обновление прошивки могло привести к случайной ошибке! Какое решение? Обновите свои коммутаторы или найдите более новый код прошивки, который может решить проблему.
Сценарий 2
Или возьмем ситуацию, когда ваши хост-серверы VMWare работают без сбоев в течение всего года, но внезапно вы начинаете видеть Пурпурные экраны смерти (PSOD) на одном из них каждые несколько дней (или даже несколько раз в день!), что заставляет VMWare HA (High Availability) запускать и перезапускать отключенные ВМ на другом доступном хосте VMWare в вашем кластере.
Вы ничего не изменили в самом программном обеспечении VMWare, оно по-прежнему работает на той же надежной версии vSphere 6.0 Update 1, которая надежно зарекомендовала себя в вашей среде. Итак, «Что изменилось» в последнее время? Подождите минутку, если подумать, хост-сервер, который в последнее время регулярно выходит из строя, неделю назад добавил к нему дополнительные 64 ГБ памяти! Возможно, стоит удалить эти дополнительные 64 ГБ памяти и посмотреть, исчезнет ли проблема. Конечно, не в первый раз новое или дополнительное оборудование было результатом основной проблемы .
Что изменилось?
Любой подмастерье или опытный ИТ-специалист, скорее всего, скажет вам, что когда дело доходит до эффективного процесса решения проблем, ВСЕГДА спрашивайте себя: «Что изменилось» в вашей среде.6. Можно ли воспроизвести проблему?
Еще один полезный шаг для эффективного решения проблем — попытаться воссоздать реальную проблему. Как обсуждалось ранее, сообщаемые проблемы могут носить постоянный или периодический характер. Потратить время на воссоздание проблемы может быть полезно и особенно полезно в тех случаях, когда вам может понадобиться использовать такие инструменты, как Wireshark, для захвата пакетов и сетевого трафика для последующего анализа и оценки. ИТ-специалисты должны использовать такие инструменты в более сложных вопросах технической поддержки, особенно когда возникает вопрос о потоке сетевого трафика или когда необходимо проверить, проходит ли трафик от исходного устройства к целевому.
Если возможно, используйте любые доступные песочницы или тестовые среды .
Наличие этих сред дает вам возможность воссоздать проблему и эффективно «сломать» вещи, не подвергая риску вашу производственную сеть или системы и не прерывая службы, на которые конечные пользователи полагаются в стандартное рабочее время.
Воссоздание проблемы также полезно в ситуациях, когда ИТ-специалисту может потребоваться также привлечение сторонней технической поддержки от поставщика. Часто у этих поставщиков есть средства для установления удаленных сеансов, чтобы получить контроль над вашим рабочим столом (или компьютером, на котором вы успешно воссоздали проблему), что дает поставщику возможность фактически видеть проблему, когда она возникает, для дальнейших действий. помогите диагностировать что происходит.
Полезные инструменты: Wireshark Wireshark — анализатор сетевых протоколов для Unix и Window. Загрузить сейчас .7. Доступны ли тесты и журналы?
Наличие какого-либо инструмента для сравнительного анализа , доступного для отслеживания и записи производительности сети и сервера, не поддается измерению с точки зрения его общей ценности, когда он помогает ИТ-специалисту отслеживать сложные технические проблемы.
Одна из ключевых областей, которую стоит проверить , когда сообщается о проблемах, смотрит на фактические ПОКАЗАТЕЛИ за исторический период времени. Метрики могут оказаться бесценными при попытке выяснить: существует ли обнаруженная проблема на самом деле или это ложное срабатывание.
Без исторических тестов анализ текущей производительности сервера может не дать каких-либо плодотворных результатов, поскольку счетчики ЦП, диска, сети и памяти КАЖЕТСЯ работают на разумном уровне, но на основе и по сравнению с тем, что в яблочко?
Благодаря доступным историческим эталонным показателям есть основа для фактического сравнения сегодняшней производительности сервера в отношении ЦП, диска, сети и памяти (и любых других показателей/счетчиков, которые вы хотите) ПРОТИВ того, для чего сервер использовал за последние дни, недели или месяцы до этого.
Какие исторические тесты могут помочь вам обнаружить, что согласно историческим данным, возможно, нет абсолютно НИКАКОЙ разницы в производительности сервера сегодня по сравнению с предыдущими днями, неделями или месяцами? Жалоба на «Файловый сервер сегодня очень медленный» оказывается ложное срабатывание в этом случае, подтвержденное показателями исторических тестов.
Поиск реальной причины и решения жалобы пользователя потребует от вас изучения других областей, помимо самого сервера. Возможно, это проблема на стороне клиента или проблема с сетью.
Наличие контрольных показателей имеет решающее значение для устранения нелогичных догадок и предположений и замены их убедительными доказательствами и фактами для поддержки вашего процесса решения проблем. Доступно бесчисленное множество вариантов программного обеспечения, которое предоставит вам данные, необходимые для метрик, хотя мы часто рекомендуем использовать PRTG от Paessler — замечательную утилиту для получения эталонных показателей в вашей сети и на серверах.
Журналы — еще одна важная вещь, которую следует учитывать в процессе устранения неполадок. Возврат к истории журналов может дать озадаченному ИТ-специалисту дополнительные подсказки относительно того, что происходит, особенно в тех случаях, когда вопрос « Когда возникла проблема?» остается без ответа.
Наличие сетевых устройств (коммутаторов, маршрутизаторов, брандмауэров, беспроводных сетей и т. д.), отправляющих данные журнала на выделенный сервер системного журнала (например, Kiwi Syslog Server от SolarWinds), дает кому-то возможность искать записи, относящиеся к определенным устройствам (путем IP-адрес) для конкретных предупреждающих сообщений или сообщений об ошибках.
Сообщения системного журнала и собранная здесь историческая информация иногда могут помочь ИТ-специалисту выбрать правильное направление, не говоря уже о том, что сами журналы могут быть чрезвычайно ценны для поставщика продукта, когда он участвует в устранении неполадок, что происходит. .
Полезные инструменты: PRTG Network Monitor Более 150 000 администраторов ежедневно используют PRTG Network Monitor для мониторинга своих локальных и глобальных сетей, серверов, веб-сайтов, устройств, URL-адресов и многого другого. Загрузить сейчас . Полезные инструменты: Kiwi Syslog Server Доступное программное обеспечение для управления сообщениями системного журнала, ловушками SNMP и журналами событий Windows.
Загрузить сейчас .8. Я официально застрял – что теперь?
Итак, вы оказались в одном из тех довольно неприятных обстоятельств, когда вы задали все правильные вопросы, покопались в своем находчивом наборе трюков и обнаружили, что исчерпали все свои технические знания и способность отследить источник проблемы. Чем вы сейчас занимаетесь?
Первый шаг НЕ ПАНИКУЙ . Эффективность решения проблем чаще всего существенно снижается, когда ИТ-специалист испытывает стресс и давление (хотя в некоторых редких случаях люди склонны преуспевать в таких сценариях «испытания огнем»). Поддержание паники поможет человеку оставаться спокойным, сосредоточенным и позволит ему логически пройти через процесс решения проблемы.
Однако это легче сказать, чем сделать, когда приходят бесчисленные электронные письма и телефонные звонки с требованием сообщить, когда источник проблемы будет устранен (и давайте не будем забывать, что потенциально разгневанные боссы, которые могут быть невежественны относительно почему проблема решается более 10 минут!).
ИТ-специалистам было бы разумно напомнить себе, что они были в подобных ситуациях в прошлом и всегда могли выяснить проблему, имея достаточно времени, чтобы правильно диагностировать, что происходит. Итак, не корите себя слишком сильно, если решение кажется недосягаемым, и вам нужно вызвать кавалерию .
Второй шаг – вызвать кавалерию! Посмотрим правде в глаза, всегда будут случаи, когда даже самому опытному ИТ-специалисту потребуется помощь коллег, поставщиков или других ресурсов . Никто из нас не способен знать абсолютно все. Когда вы обнаружите, что вам трудно, не бойтесь обратиться за помощью! Что это значит?
Это означает…
- Обращение в службу технической поддержки конкретного поставщика оборудования/программного обеспечения
- Откройте кейс, например, с поддержкой Cisco TAC
- Откройте дело, например, с поддержкой Microsoft PSS
- Обратитесь к более опытным ИТ-специалистам
- Привлеките коллегу, профессионального коллегу или коллегу
- Сотрудничайте с местным и надежным поставщиком ИТ
- Поиск помощи в онлайн-ресурсах
- Google может быть вашим другом (будьте осторожны с «быстрыми решениями», которые вы найдете)
- Просмотрите форумы конкретных поставщиков (они есть у большинства крупных поставщиков)
Не паникуйте!
Застрять на проблеме не значит сдаться.
Не бойтесь признать, что вы застряли и вам нужно привлечь дополнительные ресурсы для помощи.Краткий обзор процесса решения проблем
Не забудьте дать себе абсолютный шанс справиться с этими ужасными проблемами технической поддержки. В следующий раз, когда кто-то свяжется с вами и в панике закричит: «Электронная почта не работает!» поймите, что вы можете быстрее понять, что на самом деле происходит, и помочь минимизировать время, необходимое для решения проблемы , просто задавая правильные вопросы :
- В чем реальная проблема?
- Кто сталкивается с проблемой?
- Когда возникла проблема?
- Является ли проблема прерывистой или постоянной?
- Что недавно изменилось?
- Можно ли воссоздать проблему?
- Доступны ли контрольные показатели и журналы?
- Я официально застрял – что теперь?
Имейте в виду, однако, что вам нужны не только ответы на эти вопросы, но вам нужны точные ответы .
Как указывалось ранее, это означает, что ИТ-специалисту может потребоваться время, необходимое для проверки предоставленных им ответов. Неточные ответы и дезинформированные факты направят вас по неправильному пути устранения неполадок и излишне продлят время, необходимое для решения сложных вопросов технической поддержки. Так что излагай свои факты прямо!
Ответы на эти вопросы позволят вам сразу сузить масштаб проблемы и потенциальные проблемные зоны, провести тесты, сформулировать выводы и решить проблемы даже быстрее, чем вы могли ожидать.
Вы нашли это полезным? Пожалуйста, поделитесь им.
Методы решения проблем для высокоэффективной команды
В то время как большинство людей связывают бережливое производство с такими инструментами и принципами, как картирование потока создания ценности, поток единичных изделий, канбан, 5-S, комплексное техническое обслуживание и мероприятия по кайдзен, мало кто задумывается о более приземленных аспектах бережливого производства.
Решение проблем — один из ключей к успешному внедрению бережливого производства, поскольку оно расширяет возможности всех участников.
Бережливое производство имеет уникальный способ решения проблем. Он не просто смотрит на последствия проблемы и пытается заклеить ее пластырем. Скорее, коренная причина проблемы идентифицируется, и коренная причина, а также все способствующие факторы устраняются из системы, процесса или инфраструктуры, чтобы навсегда решить проблемы. В чем разница в этих двух подходах? Все просто: когда вы найдете и устраните коренные причины, проблема будет решена навсегда. При этом будут устранены даже другие проблемы, возникающие из-за этих основных причин.
Теперь совершенно ясно, что мы должны выяснить коренные причины проблем, прежде чем думать об их устранении в среде бережливого производства. Итак, как мы должны это сделать? Какие инструменты доступны для выполнения этих задач? Давайте посмотрим, что такое решение проблемы. Начнем с вопроса: «Что такое проблема?» Хорошее определение проблемы — это отклонение от общепризнанного стандарта.
Другими словами, вам нужно знать, как вещи должны быть, прежде чем вы сможете распознать возможную причину того, что они не таковы. После того, как проблема была признана, следует применить формальный процесс решения проблемы.
Высокопроизводительные рабочие группы обычно используют четыре инструмента для решения проблем:
.
1. Планируй, делай, проверяй, действуй (PDCA)
2. Анализ пяти причин
3. Исхакава (Фишбоун) Диаграмма
4. Упрощенный анализ видов и последствий отказов (SFMEA)
Планируй, делай, проверяй, действуй (PDCA)
Цикл Деминга PDCA предоставляет эффективные рекомендации для успешного решения проблем. Цикл
включает:
План
Четкое определение проблемы (P1)
«Четко сформулированная проблема — это наполовину решенная проблема». Хотя это кажется тривиальным шагом, команда не должна относиться к нему легкомысленно.
Важно начать этот путь решения проблем с четкой и краткой формулировки проблемы. Если это не будет сделано должным образом, это может привести к одному из следующих последствий: чрезмерное время на выявление причины из-за широкой формулировки проблемы, что предрасполагает команду к конкретному решению, или решение проблемы превращается в реализацию решения, а не в выявление первопричины и средство.
Соберите доказательства проблемы (P2)
Это задание направлено на получение информации/данных, чтобы четко продемонстрировать, что проблема действительно существует. В случае группового решения проблем это должно быть быстрым упражнением, поскольку функция проектирования надежности должна была просматривать данные, чтобы создать команду. Результатом этой деятельности будет список доказательных утверждений (или графиков), иллюстрирующих существование проблемы , ее размер и хронический характер этого.
Определение воздействий или возможностей (P3)
Эта часть сегмента «План» фокусируется на выявлении преимуществ в случае успешного решения этой проблемы.
Эту деятельность необходимо рассматривать с двух разных точек зрения, потому что работа проектной группы может принимать форму контрольной работы, например. устранение проблемы, которая стоит на пути ожидаемых результатов или чистого улучшения (попытка поднять результаты на новый уровень производительности). В каждом случае результатом этого действия будет список утверждений. Заявления о воздействии и заявления о возможностях должны быть изложены с точки зрения потерь в долларах, времени, «продукта», переделок, времени обработки и/или морального духа.
Измерение проблемы (P4)
Прежде чем приступить к решению проблемы , важно, чтобы команда быстро проверила, насколько достоверны или надежны данные, на основании которых команда принимает решение о решении проблемы. . Что касается параметра (параметров), которые используются в качестве доказательства проблемы, известна ли команде какая-либо информация, которая может поставить под сомнение достоверность, точность или надежность данных? Этот вопрос следует изучить, полагаемся ли мы на инструмент, записывающее устройство или людей для записи информации или данных.
Если команда подозревает, что существуют серьезные проблемы, которые «затуманивают» данные, то эти проблемы измерения необходимо решить, исправить и получить новые меры, прежде чем переходить к другим сегментам PDCA.
Показатели эффективности (P5)
На этом этапе команда должна определить, как они намерены измерять успех своих усилий по решению проблем. Это один из самых важных шагов в PDCA, который, безусловно, отличает его от традиционного решения проблем . Стратегия заключается в том, чтобы договориться о том, что и как, чтобы получить контрольный показатель «до» чтения, выполнить действия PDCA и повторно измерить или получить измерение «после». В этот момент команде нужно будет решить, нужно ли им повторно использовать PDCA для достижения заранее заявленной цели.
Выполнить
Генерация возможных причин (D1)
Чтобы не попасть в режим внедрения решения или решения проблемы методом проб и ошибок, команде необходимо начать с «чистого листа» и со свежей точки зрения выложить все возможные причины проблемы.
С этого момента команда может использовать данные, свои коллективные знания и опыт, чтобы отсортировать наиболее возможные или вероятные основные причины. Подобные действия помогут гарантировать, что команда в конечном итоге выявит коренные причины проблем и не остановится на лечении других симптомов. Лучшим инструментом для облегчения этого мышления является диаграмма причин и следствий, составленная теми людьми, которые наиболее осведомлены и наиболее близки к проблеме.
Выявлены причины поломки, проработаны (D2)
Прежде чем приступить к выполнению Плана действий (для устранения причины) или Плана экспериментальных испытаний, часто есть части процесса, которые «сломаны». Это может принимать самые разные формы.
Написать экспериментальный тест или план действий (D3/4)
В зависимости от типа проблемы, над которой ведется работа, стратегия PDCA будет принимать одно из двух разных направлений на данном этапе. Направление зависит от того, является ли это проблемой, основанной на данных, или проблемой, ограниченной данными.
В таблице ниже показано различие между этими двумя стратегиями и, в частности, различие между планом действий и планом экспериментальных испытаний. Обратите внимание, что в некоторых случаях необходимо будет использовать комбинацию планов действий и планов экспериментальных испытаний. То есть для некоторых областей причин подходит план действий, а для других причин в рамках одной и той же проблемы наилучшим путем является выполнение плана экспериментальных испытаний.
Написать план действий по устранению причины (D3)
Чтобы перейти к написанию Плана действий, команде необходимо провести мозговой штурм возможных решений или мер по каждой из «причинных областей» и прийти к консенсусу по приоритетным решениям. Эту работу можно выполнять в команде или разделить на подгруппы. В любом случае, вся команда должна будет прийти к соглашению о предлагаемых средствах правовой защиты и согласиться с Планом действий. План действий будет реализован в сегменте «Проверка».
Написать план экспериментального тестирования (D4)
План экспериментальных испытаний представляет собой документ, в котором показаны экспериментальные испытания, которые необходимо провести. Это позволит проверить, действительно ли идентифицированная первопричина влияет на интересующую зависимую переменную. Иногда это может быть один тест, который проверяет все причины сразу, или это может быть серия тестов.
Примечание: Если есть подозрение, что существует взаимодействие между причинами, эти причины должны быть включены в один и тот же тест.
План экспериментальных испытаний должен отражать:
Время/длина теста
Как будут изменены факторы причины во время испытаний
Зависимая переменная (переменная, на которую нужно воздействовать) представляет интерес
Любые шумовые переменные, которые необходимо отслеживать
Пункты, которые должны оставаться постоянными
Все, кто участвует в планах экспериментальных испытаний, должны быть проинформированы до проведения испытаний.
Это должно включать:
Цель теста
План экспериментальных испытаний (подробности)
Как они будут задействованы
Ключевые факторы для обеспечения хороших результатов
Когда решения выработаны, команда должна согласовать пробную реализацию решений и методику анализа данных «включить/выключить».
Идентифицированные ресурсы (D5)
После написания Плана экспериментальных испытаний или Плана действий команде будет совершенно очевидно, какие ресурсы необходимы для проведения работы. Для ресурсов, не входящих в команду, команда должна составить список того, кто нужен, по какой причине, временных рамок и приблизительного количества времени, которое потребуется. Эта информация будет передана руководству.
Пересмотренное расписание PDCA (D6)
На данный момент команда гораздо лучше понимает, что должно быть вовлечено в оставшуюся часть ее деятельности по PDCA.
Им следует скорректировать приблизительные графики, которые были спроецированы в сегменте «План». Эта информация должна быть обновлена в Плане команды, а также доведена до Руководящей группы.
Проверка/утверждение группой управления (D7)
Команда достигла критической точки в цикле PDCA. Действия, которые они собираются осуществить, будут иметь очевидное влияние и последствия для отдела. По этой причине очень важно сделать презентацию для руководства, прежде чем продолжить. Это может делать руководитель группы или вся команда. Содержание/цель данной презентации:
− Мера эффективности с мерой «до»
− Приоритетные причины
− План действий (для устранения причины) или план экспериментальных испытаний
− Пересмотренный график PDCA
Проверка
Выполнение экспериментального испытания или плана действий (C1/C2)
В зависимости от характера проблемы команда будет выполнять один из следующих шагов:
Выполнение плана(ов) экспериментальных испытаний для тестирования и проверки основных причин или
Проработайте детали соответствующих решений для каждой области причины.
Затем с помощью данных проверьте, были ли эти решения эффективными.
Выполнение плана действий (C1)
В случае Планов действий, когда решения были разработаны и согласованы командой, необходимо будет использовать методы «включить/выключить» для проверки того, что решения являются подходящими и эффективными. Чтобы следовать этой стратегии, команде необходимо определить зависимую переменную — переменную, на которую команда пытается повлиять посредством изменения причинных факторов.
Выполнение плана экспериментальных испытаний (C2)
Во время сегмента проверки должны быть проведены экспериментальные тесты для проверки всех основных приоритетных причин, проанализированы данные и сделаны выводы и согласованы с командой.
Анализ данных из экспериментального плана или плана действий (C3)
Как правило, на одного человека из команды возлагается обязанность выполнять анализ данных из плана тестирования. При необходимости этот человек должен использовать имеющиеся ресурсы отдела или предприятия, чтобы дать рекомендации относительно надлежащих инструментов анализа данных и/или интерпретации выходных данных.
Конкретные инструменты, которые следует использовать, будут зависеть от характера плана тестирования.
Решения — Вернуться к Выполнить Стадия или продолжение (C4)
Изучив выводы анализа данных о предполагаемых причинах или проверенных решениях, команда должна принять важное решение о том, какие действия следует предпринять на основе этой информации.
План реализации, чтобы сделать изменение постоянным (C5)
Этап анализа данных мог быть выполнен в любом из следующих контекстов:
После того, как план действий (решения) был выполнен, был проведен анализ данных, чтобы увидеть, повлияла ли зависимая переменная. Если выводы были благоприятными, группа могла приступить к разработке плана реализации.
Был проведен план экспериментальных испытаний; данные были проанализированы для проверки причин. Если выводы были благоприятными (выявлены важные причины), команда должна разработать решения для устранения этих причин, прежде чем приступить к разработке плана реализации.
(Например, только что с помощью плана тестирования было обнаружено, что технические различия вносят вклад в ошибку измерения.)
Силовое поле при реализации (C6)
После того, как план реализации написан, команда должна провести анализ силового поля факторов, способствующих и препятствующих успешной реализации – успех в том смысле, что результаты, наблюдаемые в тестовой ситуации, будут реализованы на постоянной основе после того, как будут найдены решения. реализовано.
Проверка/утверждение группой управления (C7)
Команда достигла очень критической точки в цикле PDCA и должна встретиться с командой управления, прежде чем продолжить. Эта встреча чрезвычайно важна, потому что команда будет двигаться вперед с постоянными изменениями, которые необходимо внести в операции. Группе управления необходимо не только одобрить эти изменения, но и то, как они будут реализованы.
Акт
Выполнение плана реализации (A1)
Если команда написала полный, четкий и хорошо продуманный план реализации, будет совершенно очевидно, какая работа должна быть выполнена, кем и когда выполнять этап «Действие» цикла PDCA.
Команда должна уделить значительное внимание тому, чтобы коммуникация и обучение проводились тщательно, чтобы сотрудники отдела знали, что меняется, почему вносятся изменения и что им нужно делать конкретно, чтобы внедрение было успешным.
После измерения эффективности (A2)
После того, как все изменения были внесены и прошло достаточно времени, чтобы результаты этих изменений возымели действие, команда должна выйти и собрать данные по всем показателям эффективности. Затем данные необходимо проанализировать, чтобы увидеть, произошел ли значительный сдвиг .
Анализ результатов и целей команды (A3)
На предыдущем шаге команда рассмотрела, повлияло ли какое-либо существенное влияние на показатель(ы) эффективности постоянное внедрение изменений. Команда не может останавливаться на достигнутом. Если ответ на этот вопрос положительный, то команда должна убедиться, что количество улучшений достаточно велико для достижения цели команды.
Сбор отзывов команды (A4)
После того как команда приняла решение об успешном завершении цикла PDCA (на основе изменения показателя эффективности), команда должна представить эту информацию руководству. Прежде чем это будет сделано, руководитель группы должен получить обратную связь от команды. Эта обратная связь будет иметь форму анкеты, которую должны заполнить все члены команды (включая руководителя группы). Результаты подсчитываются руководителем группы и заносятся в форму А3.
Заключительное собрание руководства (A5)
Перед роспуском команда должна провести заключительную встречу с руководством. Основные области, которые будут затронуты на этой встрече:
Подведите итоги реализации любых незавершенных вопросов
Просмотрите результаты измерения эффективности и сравните с командной целью
.Убедитесь, что документация команды завершена и находится в порядке
Делитесь отзывами членов команды о командном опыте (стандартные формы и неформальное обсуждение)
5 причин решения проблем
Когда у вас возникнет проблема, подойдите к тому месту, где возникла проблема, и задайте вопрос «Почему» пять раз.
Таким образом, вы найдете первопричины проблемы и сможете приступить к их лечению и устранению проблемы.
Анализ 5-Почему — это метод, который не включает сегментацию данных, проверку гипотез, регрессию или другие расширенные статистические инструменты, и во многих случаях может быть выполнен без плана сбора данных. Повторно задавая вопрос «Почему» не менее пяти раз, вы можете снять слои симптомов, которые могут привести к основной причине проблемы.
Вот простой пример применения анализа «5 почему» для определения основной причины проблемы. Предположим, что вы получили большое количество возвратов клиентов на конкретный продукт. Давайте решим эту проблему, используя пять «почему»:
.
1. Вопрос: Почему клиенты возвращают товар?
Ответ: 90 процентов возвратов приходится на вмятины на панели управления.
2. Вопрос: Почему на панели управления есть вмятины?
Ответ: Проверка панелей управления является частью процесса доставки. Таким образом, они должны быть повреждены во время транспортировки.
3. Вопрос: Почему они повреждены при транспортировке?
Ответ: Потому что они не упакованы в соответствии со спецификацией упаковки.
4. Вопрос: Почему они не упакованы в соответствии со спецификацией упаковки?
Ответ: потому что у доставки нет спецификации упаковки.
5. Вопрос: Почему у доставки нет спецификации упаковки?
Ответ: Потому что предоставление каких-либо спецификаций при отправке не является частью обычного процесса выпуска продукта.
Использование пяти «почему» в этом случае показало, что ошибка в процессе выпуска продукта привела к тому, что покупатели вернули продукт.
Схема Исикавы
В некоторых случаях проблема может быть вызвана более чем одной первопричиной или может иметь несколько воздействующих функций, которые по отдельности или в сочетании приводят к возникновению проблемы. Процесс «5 почему» может не дать возможности решить эти более сложные проблемы. Графическое представление этого анализа первопричины может быть достигнуто с помощью Исикава или Диаграмма причин и следствий .
Из-за своей формы этот процесс также называют диаграммой Fishbone Diagram . Это помогает людям сообщать об основной причине и потенциальных способствующих факторах и/или воздействующих функциях в простом и понятном графическом формате. Этот метод является очень четким способом представления взаимосвязи между основной причиной проблемы и всеми возможными факторами, которые могут быть связаны с проблемой.
Диаграмма причин и следствий или диаграмма «рыбья кость» — это графический инструмент для определения взаимосвязи между проблемой и ее потенциальными причинами. Один из наиболее эффективных способов построения такой диаграммы — провести мозговой штурм потенциальных причин в командной среде. Например, диаграмма причин и следствий может использоваться для определения возможных причин повторяющихся дефектов в производственном процессе.
Диаграмма «рыбья кость» напоминает скелет рыбы, с проблемой (проблемой или состоянием процесса) с правой стороны. Категории основных причин указаны в полях с левой стороны Диаграммы причин и следствий.
Обобщите основные причины по категориям. Обычно это «Методы», «Измерения», «Машины», «Материалы» и «Люди».
В каждой категории определите потенциальные причины проблемы, связанной с категорией. Например, если тот факт, что на сборку доставляются неправильные детали, является потенциальной причиной решаемой проблемы, это будет указано как ветвь в разделе «Материалы».
И диаграммы «рыбья кость», и анализ «Пять почему» — простые и очень полезные методы решения проблем. Один из первых шагов к созданию культуры бережливого производства — превратить каждого сотрудника в человека, решающего проблемы. Это должно начаться с обучения использованию «Пяти почему» на регулярной основе.
Упрощенный анализ видов и последствий отказов
Упрощенный анализ видов и последствий отказов (SFMEA) — это нисходящий метод анализа конструкции, который широко используется в промышленности. В США автомобильные компании, такие как Chrysler, Ford и General Motors, требуют проведения такого анализа.
Существует множество различных стандартов компаний и отраслей, но одним из наиболее широко используемых является Группа действий автомобильной промышленности (AIAG). Используя этот стандарт, вы начинаете с рассмотрения каждого компонента или функционального блока в системе и того, как он может выйти из строя, что называется режимами отказа. Затем вы определяете влияние каждого режима сбоя и его серьезность на функционирование системы. Затем вы определяете вероятность возникновения и обнаружения отказа. Процедура заключается в расчете номера приоритета риска или RPN по формуле:
RPN = Серьезность × Возникновение × Обнаружение
Второй этап заключается в рассмотрении корректирующих действий, которые могут уменьшить серьезность или частоту возникновения или повысить уровень обнаружения. Как правило, вы начинаете с более высоких значений RPN, которые указывают на наиболее серьезные проблемы, и работаете в нисходящем направлении. Затем RPN пересчитывается после определения корректирующих действий.
Цель состоит в том, чтобы получить минимальное значение RPN.
Заключение
Эти четыре инструмента могут эффективно использоваться естественными рабочими группами для решения большинства проблем, с которыми они могут столкнуться в ходе своей повседневной деятельности. Ни один из них не требует специальных навыков. Вместо этого они полагаются на местные знания, здравый смысл и логику. Совокупность знаний, опыта и навыков команды более чем достаточна для успеха.
Ежедневные советы по решению проблем в бережливой организации:
Не позволяйте тому, что может показаться «маленькими проблемами», накапливаться и превращаться в большие проблемы в будущем. Единственный способ работать над завтрашними проблемами — это работать над проблемами сегодня, пока они еще невелики.
Используйте визуальное управление и стандартные рабочие инструменты, чтобы выявлять проблемы до того, как они начнут накапливаться.
Создайте навыки, инструменты и системы, необходимые для решения этих проблем как можно скорее.
Начните использовать анализ «5 почему». Продолжайте спрашивать «Почему?» на разных этапах для того, чтобы глубже проникнуть в первопричину проблемы.
Используйте Plan-Do-Check-Act или PDCA. Без полного понимания причины того, что происходит в ситуации, организация не сможет контролировать свои процессы, чтобы поддерживать бережливое производство.
Поймите, что небольшие проблемы являются ценным вкладом в будущие результаты.
Об авторе:
Кит Мобли — консультант компании Life Cycle Engineering. Он заработал международную репутацию одного из ведущих консультантов в области оптимизации производительности предприятий, обеспечения надежности, профилактического обслуживания и эффективного управления. Он имеет более чем 35-летний непосредственный опыт корпоративного управления, проектирования процессов и устранения неполадок.
За последние 16 лет он помог сотням клиентов по всему миру достичь и поддерживать производительность мирового уровня. Мобли активно участвует в многочисленных профессиональных организациях. В настоящее время он является членом технических консультативных советов: Американского национального института стандартов (ANSI), Международной организации по стандартизации (ISO), а также Американского общества инженеров-механиков (ASME) и других. Он также является заслуженным лектором ASME International. Чтобы узнать больше, посетите www.LCE.com.
Об авторе
Техническая система: Элементы, основные определения и характеристики
В каждой технической системе есть различные компоненты, которые модифицируют, кондиционируют или преобразуют материалы; это коммуникативное средство , которое несет энергии для определенной цели. Чтобы больше узнать о предмете и методах коммуникации, необходимо провести тщательное исследование технической системы и ее истинной функции в коммуникации.
Если у вас все еще есть какие-либо сомнения относительно функционирования технической системы и составляющих ее компонентов, не переставайте читать следующее.
Содержание
- 1 Что такое техническая система?
- 2 Особенности
- 3 Развитие и этапы технической системы
- 3.1 Изобретение
- 3.2 Производительность
- 3.3 Инновации
- 3.4 Передача технологии 7 0 9 9 0 9 9 0 6 3 Рост0060 4 Значение технической системы в условиях глобализации
Что такое техническая система?
Техническая система всегда будет состоять из агентов-людей, чьи характеристики и отношения будут демонстрировать эффективность системы, к которой они принадлежат. Каждый из этих субъектов имеет функцию модификации элементов, составляющих систему, что позволяет решить рассматриваемую проблему.
Человек, понимающий техническую систему, должен обладать интеллектуальными и человеческими качествами, чтобы иметь возможность принимать решения, более соответствующие системе, к которой он принадлежит.
Для этого используется язык и графические представления, чтобы дать лучшее сообщение.
Необходимо подчеркнуть, что функция технической системы состоит в том, чтобы иметь возможность решать проблемы экономического, социального и политического характера .
Особенности
Технические системы должны в первую очередь обеспечивать эффективное решение проблем, связанных с тремя упомянутыми выше факторами. Для этого необходимо априорно распознать, какие характеристики или элементы заставляют техническую систему работать должным образом .
В свою очередь, чрезвычайно важно уметь учитывать, что каждая техническая система состоит из людей, поэтому существует вероятность того, что в ней есть какая-то ошибка. Для этого в качестве основных характеристик, которыми должна обладать всякая техническая система, были установлены следующие предпосылки:
- Люди естественной природы.
- Сырье доступно.
- Правильное соблюдение социальных стандартов и норм для обеспечения успешного сосуществования
- Объекты технического характера, предназначенные для исследования и разработки той же системы.
- Качественный персонал.
- Профессионалы с передовыми и техническими знаниями.
- Шкала положительных ценностей, преобладающих внутри организации.
Рост и этапы технической системы
Существует возможность сравнения между концепцией, охватывающей техническую систему, и тем, как она работает, используемой стартапами; является примером, который сегодня может быть связан с создание и использование стратегий решения проблем. Только то, что технические системы должны решать проблемы, связанные с кризисом населения и стартапа, является бизнес-концепцией, предназначенной для решения созданной им проблемы.
Именно тогда техническая система может укорениться и произвести существенные изменения только в том случае, если ее структура прочна и не требует переосмысления основ. Признание следующих фаз, которые происходят с технической системой, будет ключом к изучению ее работы:
Изобретение
Фаза изобретения может происходить радикальным образом, когда появление идей происходит спонтанно, в результате срочной необходимости решить конкретную проблему.
Вот почему изобретение является базовой фазой любой успешной технической системы.
Это часть значительных изменений в мировой истории, где невероятное решение возникает в результате проблемы, затрагивающей конкретное население. Метод проб и ошибок оказался правильным решением на проверку удачи в надежде решить проблему; так случилось с великими и прославленными мыслителями, которые изобрели нечто новое для человечества.
Производительность
Поскольку основная цель технических систем заключается в том, чтобы иметь возможность создавать новое воздействие посредством нового решения в политической, социальной и экономической областях ; должен иметь определенные разрешения и в любом случае бюджеты , чтобы этап разработки прошел гладко.
После того, как фаза изобретения пройдена, когда выявляются возможные решения и изучается осуществимый план; происходит фаза развития, которая приводит в движение разрешение конфликта. В целом вы ищете радикальных и позитивных изменений.
Инновации
Все технические системы проходят этапы эволюции, которые обеспечивают правильное развитие. На этапе инноваций компоненты системы должны гарантировать, что решения, предоставляемые обществу, являются инновационными .
Здесь система может укрепиться и достичь нового статуса, гарантирующего ваше пребывание, в то же время продолжая решать проблемы того же характера.
Передача технологии
Эта фаза наступает, когда система добилась успеха в нескольких областях, и когда использование технологии до достичь более высоких уровней системного синтеза.
Передача технологий имеет определенные ограничения, которые должны обеспечить соответствие технической системы, прежде чем она сможет расширить свои горизонты.
Рост
Последней, но не менее важной фазой системы является рост, он происходит только в том случае, если предыдущие фазы были выполнены успешно и если есть доказательства того, что такая система может быть устойчивой с течением времени.
Однако суметь утвердиться в обществе, где развиваются разнообразные технические системы, — трудная задача для того, кто зарождается. Именно тогда фаза роста и стабилизации является наиболее сложной, поскольку она должна оставаться стойкой в условиях конкуренции. Поэтому, прежде чем структурировать техническую систему, возможностей для изменений в экономике и обеспечить, чтобы решения исполнительной власти не влияли на эту систему.
Важность технической системы в условиях глобализации
Коммуникация всегда играла фундаментальную роль в развитии обществ, она зависит от них, гарантируя, что системы, которые их строят, отвечают целям демократической страны.
Технические системы приобретают все большее значение, когда дело доходит до создания новых стратегий развития , а на это способны только демократические и свободные от долгов страны, где достижения техники позволяют человеку находить решения проблем, которых должно быть все меньше и меньше.
ТРИЗ Технические системы – Центр технических инноваций, ООО
Перейти к содержимому
Как следует из его биографии, Генрик Альтшуллер проанализировал тысячи мировых патентов в ведущих областях техники. Затем он проанализировал решения, которые, по его мнению, были наиболее эффективными. Эта работа дала первое понимание тенденций или закономерностей эволюции технических систем. Он также заложил основу для развития аналитического подхода к решению изобретательских задач, ставшего впоследствии основой ТРИЗ, его теории решения изобретательских задач с ее аксиомой: эволюция всех технических систем подчиняется объективным законам.
Эти законы показывают, что в ходе эволюции технической системы улучшение любой части этой системы, уже достигшей вершины функциональной эффективности, приведет к конфликту с другой частью. Этот конфликт приведет к возможному улучшению менее развитой части. Этот непрерывный самоподдерживающийся процесс приближает систему к ее идеальному состоянию.
Понимание этого эволюционного процесса позволяет прогнозировать будущие тенденции развития технической системы. За последние 40 лет ТРИЗ превратилась в набор практических инструментов для изобретения и решения технических задач различной сложности. Сегодня мы можем выделить несколько основных инструментов ТРИЗ, а также другие методы и приемы, которые в совокупности составляют то, что известно как систематическая инновация. Ученики и последователи Альтшуллера разрабатывали эти дополнительные техники в течение последних 15 лет. Этот раздел представляет собой краткое введение в некоторые основные инструменты ТРИЗ. Он здесь по двум причинам:
Во-первых, для новых читателей важно сначала изучить терминологию ТРИЗ и ее значение, чтобы они могли эффективно использовать инструменты и концепции ТРИЗ для решения проблем.
Во-вторых, важно, чтобы читатель был знаком с философией, лежащей в основе инструментов и техник ТРИЗ, чтобы иметь возможность в полной мере их применять.
Все, что выполняет функцию, является технической системой.
Примеры технических систем включают автомобили, ручки, книги и ножи. Любая техническая система может состоять из одной или нескольких подсистем. Автомобиль состоит из подсистем двигателя, рулевого механизма, тормозов и так далее. Каждая из них также является технической системой сама по себе (со своим собственным рядом подсистем) — и каждая выполняет свою собственную функцию. Иерархия технических систем простирается от наименее сложных, состоящих всего из двух элементов, до самых сложных, со многими взаимодействующими элементами.
В таблице ниже показана иерархия технической системы под названием «Транспорт». В левой колонке указаны названия технических систем. Они расположены в порядке убывания. Горизонтальные строки содержат названия подсистем, принадлежащих технической системе , описанной слева. Например, техническая система «Тормоз» является подсистемой технической системы «Автомобиль», а также надсистемой технической системы «Колодка». Когда техническая система выполняет неадекватные или вредные функции, возможно, ее необходимо улучшить.
Это требует воображаемой редукции системы к простейшему состоянию. В ТРИЗ простейшая техническая система состоит из двух элементов с переходом энергии от одного элемента к другому. Мел и классная доска вместе не являются технической системой, если некоторая энергия (механическая сила) не проходит через мел, заставляя его взаимодействовать с классной доской.
Transportation | Drivers | |||
Power train | Brakes | Heating | Steering | |
Тормоза | Педаль тормоза | Гидроцилиндры | Brake pad assembly | |
Brake pad assembly | Mounting plate | Rivets | ||
Brake pad | Particles A | Particles B | Химическая связь | |
Химическая связь | Молекулы А | Молекулы A |
Подсистемы для технических систем
Техническая система «мел, доска и прикладная сила» может тогда стать функциональной — 3lkboard
(полная минимальная техническая система) Мел и доска , как отдельные элементы, каждая из которых является независимой технической системой.
Мел имеет молекулярную структуру. Взаимодействие различных химических элементов в его структуре создает связь, создавая материал, называемый «мел». Если качество соединения требует улучшения, необходимо проанализировать техническую систему молекулярной структуры. В то же время мел является подсистемой надсистемы классная доска . Все подсистемы взаимосвязаны друг с другом в рамках вышестоящей системы. Изменения в любой одной подсистеме могут вызвать изменения в более высоких надсистемах. При решении технической задачи всегда учитывайте взаимодействие существующей технической системы с системами над и под ней. Кроме того, технические системы подобны биологическим системам. Они не бессмертны. Они появляются, созревают и умирают — только для того, чтобы быть замененными новыми системами.
Социально-технические системы: от методов проектирования к системной инженерии | Взаимодействие с компьютерами
Журнальная статья
Гордон Бакстер,
Гордон Бакстер ⁎
Ищите другие работы этого автора на:
Оксфордский академический
Google ученый
Ян Соммервиль
Ян Соммервиль
Ищите другие работы этого автора на:
Оксфордский академический
Google ученый
Взаимодействие с компьютерами , том 23, выпуск 1, январь 2011 г.
, страницы 4–17, https://doi.org/10.1016/j.intcom.2010.07.003
Опубликовано:
7 августа 2010 г.
История статьи
Получено:
09 ноября 2009 г.
Получена редакция:
30 июля 2010 г.
Принято:
31 июля 2010 г.
Опубликовано:
7 августа 2010 г.
- Разделенный вид
- Содержание статьи
- Рисунки и таблицы
- видео
- Аудио
- Дополнительные данные
Цитировать
Cite
Гордон Бакстер, Ян Соммервиль, Социально-технические системы: от методов проектирования к системной инженерии, Взаимодействие с компьютерами , том 23, выпуск 1, январь 2011 г.
, страницы 4–17, https://doi.org/10.1016/j.intcom.2010.07.003Выберите формат Выберите format.ris (Mendeley, Papers, Zotero).enw (EndNote).bibtex (BibTex).txt (Medlars, RefWorks)
Закрыть
Разрешения
- Электронная почта
- Твиттер
- Фейсбук
- Подробнее
Фильтр поиска панели навигации Взаимодействие с компьютерамиЭтот выпускЖурналы BCSВзаимодействие человека с компьютеромКнигиЖурналыOxford Academic Термин поиска мобильного микросайта
Закрыть
Фильтр поиска панели навигации Взаимодействие с компьютерамиЭтот выпускЖурналы BCSВзаимодействие человека с компьютеромКнигиЖурналыOxford Academic Термин поиска на микросайте
Advanced Search
Abstract
Общепризнано, что применение социотехнического подхода к разработке систем приводит к созданию систем, более приемлемых для конечных пользователей и обеспечивающих большую ценность для заинтересованных сторон.
Несмотря на это, такие подходы не получили широкого распространения. Мы анализируем причины этого, выделяя некоторые проблемы с более известными методами социотехнического проектирования. Основываясь на этом анализе, мы предлагаем новую прагматическую основу для социотехнической системной инженерии (STSE), основанную на (в основном независимых) исследованиях групп, изучающих рабочий дизайн, информационные системы, совместную работу с компьютерной поддержкой и когнитивную системную инженерию. STSE устраняет традиционный разрыв между организационными изменениями и развитием системы, используя два основных типа деятельности: информирование и повышение осведомленности; и конструктивное взаимодействие. Из структуры мы определяем первоначальный набор междисциплинарных исследовательских проблем, которые касаются того, как применять социально-технические подходы экономически эффективным способом и как облегчить интеграцию STSE с существующими системами и подходами к разработке программного обеспечения.
1 Введение
Методы проектирования социотехнических систем (STSD) представляют собой подход к проектированию, учитывающий человеческие, социальные и организационные факторы, 1 , а также технические факторы при проектировании организационных систем. Они имеют долгую историю и предназначены для обеспечения совместного рассмотрения технических и организационных аспектов системы. Результатом применения этих методов является лучшее понимание того, как человеческие, социальные и организационные факторы влияют на способы выполнения работы и использования технических систем. Это понимание может способствовать разработке организационных структур, бизнес-процессов и технических систем. Несмотря на то, что многие менеджеры осознают важность социально-технических вопросов, методы социально-технического проектирования используются редко. Мы подозреваем, что причинами их неприменения являются, прежде всего, трудности использования методов и неразрывность этих методов как с инженерно-техническими вопросами, так и с вопросами индивидуального взаимодействия с техническими системами.
Основная предпосылка социотехнического мышления заключается в том, что проектирование систем должно быть процессом, учитывающим как социальные , так и технические факторы, влияющие на функциональность и использование компьютерных систем. Обоснование принятия социотехнических подходов к проектированию систем заключается в том, что отказ от них может увеличить риск того, что системы не внесут ожидаемого вклада в достижение целей организации. Системы часто соответствуют их техническим «требованиям», но считаются «неудачными», потому что они не обеспечивают ожидаемой поддержки реальной работы в организации. Источник проблемы заключается в том, что техноцентрические подходы к проектированию систем должным образом не учитывают сложные отношения между организацией, людьми, реализующими бизнес-процессы, и системой, которая поддерживает эти процессы (Норман, 19).93; Гоген, 1999).
Здесь мы утверждаем, что необходим прагматичный подход к проектированию социотехнических систем, основанный на постепенном внедрении социотехнических соображений в существующие процессы закупок и разработки программного обеспечения.
Мы стремимся решать проблемы юзабилити и несовместимости методов разработки социотехнических и технических систем. Нашей долгосрочной исследовательской целью является развитие области социально-технических систем (STSE). Под этим мы подразумеваем систематическое и конструктивное использование социотехнических принципов и методов при закупке, спецификации, проектировании, тестировании, оценке, эксплуатации и развитии сложных систем.
Мы считаем, что недостаточно просто проанализировать ситуацию с социотехнической точки зрения, а затем объяснить этот анализ инженерам. Мы также должны предложить, как социально-технический анализ может быть конструктивно использован при разработке и развитии систем. Многие компании вложили значительные средства в методы и инструменты разработки программного обеспечения, поэтому социотехнические подходы будут успешными только в том случае, если они сохранят эти методы и будут совместимы с ними. Мы должны избегать терминологии, чуждой инженерам, разрабатывать подход, который они могут использовать, и создавать ценность, пропорциональную затраченному времени.
Это непростые задачи, и для их достижения мы должны опираться на результаты исследований в различных дисциплинах. Существует как минимум четыре крупных исследовательских сообщества, которые изучали и решали социально-технические проблемы, влияющие на спецификацию, проектирование и эксплуатацию сложных компьютерных систем:
Исследователи, заинтересованные в работе в целом и на рабочем месте. Интерес к дизайну работы был первоначальным стимулом для предложения социотехнических подходов. Мамфорд (1983) и исследования Исона (1988) характеризуют подход этого сообщества. Первоначальная цель заключалась в том, чтобы сделать работу более гуманной, и основное внимание было уделено производственным системам. Однако по мере того, как компьютеры стали широко использоваться на рабочих местах, общество также стало изучать взаимосвязь между работой и ее компьютерной поддержкой, отметив, например, что компьютерная система может формировать и ограничивать методы работы (Eason, 1997).
Исследователи, интересующиеся информационными системами. Информационные системы — это крупномасштабные системы, которые поддерживают работу предприятия, и это сообщество на ранней стадии осознало важность социально-технических проблем (например, Taylor, 19).82). Это сообщество, как правило, имеет широкий взгляд на отношения между информационными системами и предприятием, а не сосредотачивается на конкретных аспектах компьютерной работы (например, Avison et al., 2001).
Исследователи, заинтересованные в совместной работе с компьютерной поддержкой (CSCW). Это сообщество сосредоточилось на мелочах работы, утверждая, что детали работы, как их понимают с помощью этнографических исследований, глубоко влияют на то, как используются компьютерные системы. Основополагающая книга Сачмана (1987), за которым последовала работа в этой области, последовало множество этнографических исследований систем в различных условиях (Ackroyd et al., 1992; Bentley et al., 1992a; Heath and Luff, 1992; Heath et al.
, 1994; Rouncefield, 1998; Кларк и др., 2003). Многие из них были связаны с совместной работой (например, в диспетчерских), и большинство из них не рассматривали более широкие проблемы предприятия, влияющие на системные требования и дизайн.Исследователи, интересующиеся инженерией когнитивных систем. Это сообщество, представленное работами (Hollnagel and Woods, 2005; Woods and Hollnagel, 2006), в первую очередь интересовалось отношениями между человеческими и организационными проблемами и системными сбоями. Их основное внимание было сосредоточено на системах управления и здравоохранении, и это сообщество не слишком интересовалось более широкими информационными системами.
Несмотря на то, что у этих сообществ была некоторая взаимная осведомленность, мы считаем справедливым сказать, что между сообществами было относительно небольшое взаимное опыление. Например, в обзорной статье Мамфорда (2006) нет ссылок на направления работы в CSCW или инженерии когнитивных систем, а также мало ссылок на литературу по информационным системам.
Рядом с этими сообществами, с некоторой осведомленностью о социально-технических проблемах, находится исследовательское сообщество HCI. На некоторые области человеко-компьютерного взаимодействия явно повлияли социотехнические идеи, включая удобство использования (например, Нильсен, 1993; Мэйхью, 1999; Krug, 2005) и проектирование систем, ориентированных на человека/пользователя (например, Gould and Lewis, 1985; Norman and Draper, 1986; Gulliksen et al., 2003). Целостный дизайн, например, определяется Gulliksen et al. (2003) в качестве ключевого принципа, и они отмечают необходимость четкого учета рабочего контекста и социальной среды. В более общем плане основное внимание уделялось привлечению внимания к социально-техническим вопросам (например, в Dix et al., 2004 есть глава по этой теме). Было проведено мало исследований о том, как эти социально-технические проблемы могут напрямую повлиять на дизайн интерфейса сложной программной системы (и это понятно: мы считаем, что это важная исследовательская задача).
Точно так же некоторые исследователи из вездесущего компьютерного сообщества находились под влиянием социотехнического мышления (Crabtree et al., 2006), хотя большинство исследований в этой общей области сосредоточено на разработке и оценке новых технологий.
Мы считаем, что нам необходимо объединить работу этих разрозненных сообществ под общим заголовком инженерии социотехнических систем. Поэтому наша цель здесь состоит в том, чтобы обобщить вклад различных исследовательских сообществ в этой области и предложить практическое видение дальнейшего развития. Мы не даем полного обзора проектирования социотехнических систем (это было бы невозможно долго). Вместо этого мы представляем различные точки зрения на STSD, которые мы используем в качестве основы для введения прагматической структуры для STSE, которая намеренно ограничена по объему, но оставляет место для применения различных подходов STSD. В этой статье мы сосредоточили наши обсуждения на организационных системах, но мы считаем, что STSE применима и к другим типам систем, основанных, например, на коммерческом готовом оборудовании и приложениях, или бытовых системах.
После того, как мы изложили нашу структуру, мы продолжаем предлагать программу исследований для социотехнической системной инженерии, в которой мы определяем исследовательские проблемы, которые необходимо решить, чтобы сделать STSE практической реальностью.
В разделе 2 вводится понятие STSD, а в разделе 3 кратко обсуждаются подходы к STSD. В разделе 4 обсуждаются недостатки этих существующих подходов. Раздел 5 вводит понятие социотехнической системной инженерии, определяя два основных типа деятельности STSE. В заключение мы определяем нерешенные вопросы исследований, которые можно использовать для формирования дисциплины социотехнической системной инженерии.
2 Проектирование социотехнических систем
Термин социотехнических систем первоначально был придуман Эмери и Тристом (1960) для описания систем, включающих сложное взаимодействие между людьми, машинами и аспектами окружающей среды рабочей системы — в настоящее время это взаимодействие характерно для большинства корпоративных систем.
Следствием этого определения является то, что все эти факторы — люди, машины и контекст — необходимо учитывать при разработке таких систем с использованием методов STSD. На самом деле эти методы больше похожи на философию, чем на методы проектирования, которые обычно ассоциируются с системной инженерией (Mumford, 2006). Методы STSD в основном дают советы разработчикам симпатических систем, а не подробные обозначения и процесс, которому следует следовать.
Термин социо-технические системы в настоящее время широко используется для описания многих сложных систем, но есть пять ключевых характеристик открытых социотехнических систем (Badham et al., 2000):
Системы должны иметь взаимозависимые части.
Системы должны адаптироваться и достигать целей во внешней среде.
Системы имеют внутреннюю среду, состоящую из отдельных, но взаимозависимых технических и социальных подсистем. 2
Системы имеют эквифинальность.
Другими словами, системные цели могут быть достигнуты более чем одним способом. Это означает, что при разработке системы необходимо сделать выбор конструкции.Производительность системы зависит от совместной оптимизации технической и социальной подсистем. Сосредоточение внимания на одной из этих систем в ущерб другой может привести к снижению производительности и полезности системы.
Методы STSD были разработаны для облегчения проектирования таких систем. Мы ограничили наше рассмотрение здесь этим классом систем и не рассматриваем, например, глубоко укоренившиеся системы, в которых обычно не задействована социальная подсистема.
С момента создания института, который сейчас называется Тавистокским институтом, в период сразу после Второй мировой войны и до наших дней было предпринято несколько попыток применить идеи STSD. Некоторые из них были успешными, другие менее успешными (Mumford, 2006). Преобладающий климат в конкретной компании (а иногда и в стране) влиял на отношение к идее STSD: там, где отношение было положительным, это часто приводило к успешному восприятию идей.
Mumford (2006) представляет исторический обзор развития STSD. Общая цель состояла в том, чтобы исследовать организацию труда, при этом ранняя работа в STSD была сосредоточена в основном на обрабатывающей промышленности и производственных отраслях, таких как угольная, текстильная и нефтехимическая промышленность. Цель состояла в том, чтобы увидеть, можно ли сделать работу в этих отраслях более гуманной. Другими словами, намерение состояло в том, чтобы отойти от механистического взгляда на работу, охватываемого Тейлором (19).11) принципы научного управления, которые во многом опирались на специализацию труда и разделение труда.
Расцвет STSD пришелся, пожалуй, на 1970-е и начало 1980-х годов. Это было время, когда была нехватка рабочей силы, и компании стремились использовать все доступные средства, чтобы сохранить свой существующий персонал. Помимо обычных культурных и социальных причин, компании также могут видеть хорошие деловые причины для принятия социотехнических идей.
Система XSEL (eXpert SELLer) корпорации Digital Equipment Corporation (DEC), например, была разработана с использованием STSD (см. Mumford and MacDonald, 19).89 для ретроспективы). Это была экспертная система, разработанная, чтобы помочь торговому персоналу DEC помочь клиентам в правильной настройке их компьютеров VAX. Эта система имела успех, и на пике своего развития семейство экспертных систем, включая XSEL, которые использовались для поддержки конфигурации и определения местоположения компьютеров DEC-VAX, как утверждалось, экономило компании десятки миллионов долларов в год (Баркер и О. Коннор, 1989). Конечно, невозможно оценить вклад STSD в этот успех, но пример показывает, что социотехнические подходы могут быть эффективно использованы в реальной системной инженерии.
Напротив, вторая половина 1980-х и 1990-е годы, возможно, были самой низкой точкой в истории STSD. Внедрение методов бережливого производства и реинжиниринга бизнес-процессов преобладало, а STSD в значительной степени отодвигался на второй план.
Однако Данкбаар (1997) предположил, что все эти разные методы (STSD, BPR и т. д.) могут учиться друг у друга. В конце 1980-х и начале 1990-х годов также появились этнографические исследования труда, чему способствовало основополагающее исследование Сачмана (1987) в Xerox PARC. Эти этнографические подходы (например, Heath and Luff, 1991) подчеркнул важность социотехнических вопросов при проектировании систем с интенсивным использованием программного обеспечения (например, Blomberg, 1988).
В 21 веке наблюдается возрождение интереса к социотехническим подходам, поскольку отрасли промышленности обнаружили снижение отдачи от инвестиций в новые методы разработки программного обеспечения. Однако социотехнические идеи и подходы не всегда могут прямо называться таковыми (Avgerou et al., 2004). Идеи появляются в таких областях, как методы совместного проектирования, CSCW и этнографические подходы к дизайну. Действительно, одним из ключевых принципов STSD является акцент на методах участия, когда конечные пользователи участвуют в процессе проектирования (например, Гринбаум и Кинг, 19).
91). Однако эти методы, все из которых уходят своими корнями в STSD, различаются по важным аспектам. Совместное проектирование, которое охватывает целый ряд методов (например, см. Muller et al., 1993), часто предполагает, что пользователи (или представители пользователей) фактически перемещаются на территорию разработчиков системы на время проекта. Напротив, эмпатический дизайн (Leonard and Rayport, 1997) и контекстуальный дизайн (например, Beyer and Holtzblatt, 1999), которые отражают идеи STSD, принимают обратную точку зрения и помещают разработчиков в мир пользователей как часть процесса разработки.
Область CSCW возникла отчасти в ответ на необходимость обсудить разработку приложений групповой поддержки (Грудин, 1994), но она имеет неявные корни в социотехническом мышлении. Боукер и др. (1997) делают связь явной, касаясь социотехнической системы и CSCW, как и недавний специальный выпуск журнала Computer-Supported Cooperative Work , посвященный CSCW и надежности в системах здравоохранения (Procter et al.
, 2006). Область надежности 3 (Laprie, 1985; Avizienis et al., 2004) также неразрывно связана с социотехническими системами, хотя в этой области иногда используется термин «компьютерные системы» для обозначения социотехнических систем.
Методы STSD по-прежнему рекомендуются для разработки систем и, по-видимому, особенно подходят для некоторых областей применения. Например, с конца 1990-х годов STSD часто пропагандировался в медицинской информатике для разработки медицинских приложений (например, Whetton, 2005). Многие такие системы используются недостаточно, потому что они вводят методы работы, которые противоречат другим аспектам работы пользователя, или требуют изменений в процедурах, затрагивающих обязанности других людей. Одним из ключей к разработке систем, приемлемых для пользователей, является детальное понимание лежащих в их основе рабочих структур. Другими словами, требуется социотехнический подход (Берг, 1999, 2001; Берг и Туссен, 2003).
Совсем недавно в Великобритании потребность в STSD была выдвинута на первый план в связи с проблемами, связанными с текущей Национальной программой информационных технологий Национальной службы здравоохранения (NPfIT; см.
Brennan, 2007 для комментариев к программе). Несмотря на то, что многие современные разработки в рамках NPfIT были навязаны по существу сверху вниз, все еще есть области, в которых STSD играет роль, пусть даже только на местном уровне (Eason, 2007).
Хотя подавляющее большинство приложений было реализовано на рабочем месте, социотехнические идеи в равной степени применимы и в других условиях, где развертываются технологии. В последние годы наблюдается все большее распространение технологий в доме, особенно технологий умного дома и вспомогательных технологий. Требования к домашним системам несколько отличаются от требований к системам на рабочем месте. Sommerville and Dewsbury (2007), например, разработали модель проектирования надежных бытовых систем, основанную на социально-техническом подходе, согласно которой система включает пользователя, домашнюю среду и установленную технологию.
3 Подходы к проектированию социотехнических систем
Проектирование социотехнических систем проявляется в широком спектре различных методов.
Разные традиции, развившиеся в разных странах в разное время, привели к разным подходам (см. Mumford, 2006, довольно полный исторический обзор). Отдельные методы в некоторой степени отражают различные национальные культуры и подходы к работе и организации труда. Следствием этого обычно было то, что каждый метод адаптирован к конкретному рынку, что отчасти объясняет, почему никогда не предпринималось каких-либо значительных или успешных попыток интегрировать подходы для создания более общего стандартизированного метода STSD.
Переносимость доступных методов ограничена. Как правило, те, кто разработал метод, добились наибольшего успеха в его применении. ЭТИКА Мамфорда (1983, 1995), например, в основном использовалась в США, когда Мамфорд работал непосредственно с базирующимися там организациями, такими как DEC (см. Раздел 2).
Поскольку природа различных рынков изменилась, методы не всегда успевали за ними. В некоторых случаях методы были усовершенствованы реактивным образом — например, ETHICS недавно была объединена с гибкими методами разработки программного обеспечения (Hickey et al.
, 2006). Однако в большинстве случаев не было никакого пересмотра роли прежних фундаментальных представлений о ЗТСР. Связано ли это с тем, что STSD не считается актуальным для современных методов работы, или потому, что эти подходы просто игнорируются, остается открытым вопросом. STSD остается активной областью исследований и практики, хотя во многих случаях применяются идеи, а не оригинальные методы.
Несмотря на то, что понятие участия пользователя лежит в основе STSD, использование ориентированных на пользователя методов в целом вызывает разочарование. Eason (2001), например, обнаружил, что ни один из 10 наиболее широко пропагандируемых методов (включая социотехнический дизайн) не получил широкого распространения. Кроме того, даже там, где методы использовались, участие пользователей по-прежнему в значительной степени способствовало развитию техноцентрической системы. Пользователи не рассматривались как участники процесса разработки интегрированных систем для создания системы, в которой должным образом учитывались бы социальные и организационные требования.
Одной из областей, где к участию пользователей относятся серьезно, является разработка программного обеспечения с использованием гибких методов, таких как экстремальное программирование (XP), метод разработки динамических систем (DSDM) и Scrum (обзор и анализ см. в Abrahamsson et al., 2002). этих методов). Эти методы предусматривают, по крайней мере, некоторое участие пользователя лицом к лицу — хотя на практике то, кто играет роль пользователя, часто может зависеть от того, кто доступен для общения с разработчиками, — и используют короткие итерационные циклы разработки для разработки эволюционных прототипов решений в таким образом, который учитывает местные непредвиденные обстоятельства (например, см. Boehm and Turner, 2004). Однако гибкие методы в основном связаны с требованиями конечных пользователей и делают упрощенные предположения о том, что: (а) доступны подходящие пользователи для взаимодействия с командой разработчиков и (б) требования пользователей соответствуют более широким организационным требованиям.
Хотя гибкие методы, безусловно, порождают интересные идеи, их внимание к взаимодействию с отдельными пользователями не учитывает потребности в более широкой социотехнической осведомленности в системной инженерии.
В дополнение к подходам, описанным в обширном обзоре Мамфорда (2006), мы также определили несколько других подходов, которые охватывают социотехнические идеи. Мы считаем, что эти другие подходы также могут помочь в разработке социотехнических систем:
Методология мягких систем (SSM; Checkland, 1981; Checkland and Scholes, 1999), которая основана на идеях исследования действий, имеет свои корни. в системной инженерии, а не в социальных науках. ССМ рассматривает целенаправленное действие как систему: логически связанные действия связаны между собой как единое целое, а эмерджентным свойством целого является его целенаправленность. Одной из ключевых особенностей SSM является его сосредоточенность на развитии понимания проблемы (SSM использует более общий термин «проблемная ситуация»).
Это понимание принимает во внимание роли, обязанности и интересы заинтересованных сторон, связанные с конкретной проблемой. Понимание проблемы обеспечивает основу для решения, которое опять же учитывает различные точки зрения заинтересованных сторон. SSM прямо признает, что окончательное решение основано на попытке учесть мнения (и потребности) различных заинтересованных сторон. Мы считаем, что понимание проблем является одной из основных сильных сторон SSM, но его также можно использовать для разработки информационных моделей более технических аспектов системы. Он также использовался для оценки существующих информационных систем (Checkland and Poulter, 2006).Когнитивный анализ работы (CWA; Rasmussen et al., 1994b; Vicente, 1999) был разработан для анализа работы, которую могут выполнять сложные социально-технические системы. Таким образом, это формативный подход, основанный на прогнозировании того, что может сделать система, в отличие от большинства подходов, которые являются либо нормативными (как работа должна выполняться ), либо описательным (как выполняется работа ).
Социально-технический метод проектирования рабочих систем (Waterson et al., 2002) фокусируется на проектировании систем. Он используется для определения задач, которые должны быть распределены между машинами (и, следовательно, реализованы с использованием ИТ), а также учитывает те задачи, которые должны выполняться людьми (как индивидуально, так и в составе команд). Этот метод предназначен для общего использования в системах распределения функций и социально-технических работ.
Этнографический анализ рабочего места (например,suchman, 1987; Hughes et al., 1997; Viller and Sommerville, 2000; Martin and Sommerville, 2004) подчеркивает ситуативный характер действия и исследует, как результаты этнографических исследований могут информировать дизайн социотехнических систем. Этнографический анализ рабочего места в основном сосредоточен на оперативных вопросах, влияющих на функциональность и использование системы. Он показал, насколько распространены обходные пути и динамические модификации процессов, и показал важность осведомленности и физического рабочего места для выполнения работы.
Контекстный дизайн (Бейер и Хольцблатт, 1999) направлен на проектирование продуктов непосредственно на основе понимания дизайнером того, как клиент на самом деле выполняет работу. Он основан на представлении о том, что любая система по своей сути воплощает в себе определенный способ работы, который затем в значительной степени определяет, как система будет использоваться и как она будет структурирована. Контекстный дизайн порождает действия, которые сосредоточены на интерфейсе дизайна и, в частности, на клиентах и их работе.
Когнитивная системная инженерия (Hollnagel and Woods, 2005; Woods and Hollnagel, 2006) занимается анализом организационных вопросов и предлагает некоторую практическую поддержку для проектирования систем. CSE использует наблюдение как инструмент для анализа работы в контексте и использует абстракцию результатов для выявления закономерностей в наблюдениях, которые происходят в рабочих условиях и ситуациях, тем самым улучшая понимание источников опыта и неудач.
Дизайн, ориентированный на человека (Международная организация по стандартизации, 2010 г.), который следует таким принципам, как создание дизайна на основе четкого понимания пользователей, их задач и среды, в которой эти задачи выполняются. Он также включает в качестве одного из четырех основных видов деятельности по проектированию понимание и спецификацию контекста, в котором будет использоваться система, и явно относится к рассмотрению социальных и культурных факторов, включая методы работы и структуру организации.
Методы STSD можно разделить на категории в зависимости от того, насколько хорошо они справляются с тремя основными этапами жизненного цикла системной инженерии: анализом, проектированием и оценкой. Есть также несколько общих наборов принципов, которые обеспечивают абстрактное руководство для разработки социотехнических систем, а не непосредственно поддерживают подробные аспекты разработки систем. К ним относятся принципы Чернса (1976, 1987) и Клегга (2000), которые охватывают такие аспекты, как власть и авторитет (Чернс, 1987), а также тот факт, что дизайн должен отражать потребности заинтересованных сторон (Clegg, 2000).
В таблице 1 показано, как некоторые из наиболее известных подходов соотносятся с различными фазами жизненного цикла системной инженерии. Все методы, как правило, наиболее тесно связаны с одной конкретной фазой жизненного цикла, хотя они все же обеспечивают некоторую поддержку для других фаз. Хотя несколько подходов обеспечивают поддержку большинства этапов жизненного цикла системной инженерии, мы считаем, что ни один из подходов не обеспечивает полного охвата всех этапов.
4 Проблемы с существующими подходами к проектированию социально-технических систем
Разработка методов STSD выявила и предприняла попытку решить реальные проблемы в понимании и разработке сложных организационных систем, которые в настоящее время неизбежно полагаются на крупномасштабные системы с интенсивным использованием программного обеспечения. Однако, несмотря на положительный опыт демонстрационных проектов, эти методы не оказали существенного влияния на практику промышленной разработки программного обеспечения.
Причины этой неудачи в принятии и продолжении использования подходов STSD анализировались в нескольких источниках и с разных точек зрения (например, Mathews, 19).97; Мамфорд, 2000, 2006). Ниже мы резюмируем основные проблемы, выявленные этими авторами, а также обсуждаем другие вопросы, возникшие при нашем собственном использовании методов STSD.
Таблица 1
Взаимосвязь между подходами к проектированию социотехнических систем и этапами разработки жизненного цикла системной инженерии. Двойная галочка (✓✓) указывает на то, что конкретный подход к проектированию обеспечивает надежную поддержку соответствующей фазы жизненного цикла; одиночная галочка (✓) указывает на некоторую поддержку.
| . | Общий . | Анализ . | Дизайн . | Оценка . | ||
|---|---|---|---|---|---|---|
| Cherns’ (1976) and Cherns (1987) principles | ✓✓ | |||||
| Clegg’s (2000) principles | ✓✓ | |||||
Scandinavian approaches (e. g., Bjerknes and Bratteteig, 1995) | ✓ | ✓ | ✓ | |||
| Dutch Integral Organisation Renewal (De Sitter et al., 1997) | ✓ | ✓ | ✓ | |||
| этика (Mumford, 1983, 1995) | ✓ | ✓ Socdest Alsemser.99) | ✓✓ | |||
| Socio-technical method for designing work systems (Waterson et al., 2002) | ✓ | ✓ | ||||
| Ethnographical Workplace analysis ( Hughes et al., 1992) | ✓ | ✓ | ||||
| Contextual design (Beyer and Holtzblatt, 1999) | ✓ | ✓✓ | ✓ | |||
| Cognitive systems engineering (Hollnagel and Woods, 2005) | ✓ | ✓✓ | ✓ | ✓ | ||
| Human-centred design (International Standards Organisation, 2010) | ✓ | ✓ | ✓ | ✓ |
. | Общий . | Анализ . | Дизайн . | Оценка . | ||
|---|---|---|---|---|---|---|
| Cherns’ (1976) and Cherns (1987) principles | ✓✓ | |||||
| Clegg’s (2000) principles | ✓✓ | |||||
| Скандинавские подходы (например, Bjerknes and Bratteteig, 1995) | ✓ | ✓ | ✓ | |||
| Dutch Integral Organisation Renewal (De Sitter et al., 1997) | ✓ | ✓ | ✓ | |||
| ETHICS (Mumford, 1983, 1995) | ✓ | ✓✓ | ✓ | ✓ | ||
| ✓ | ✓ | |||||
| Ethnographical Workplace analysis (Hughes et al., 1992) | ✓ | ✓ | ||||
| Contextual design (Beyer and Holtzblatt, 1999) | ✓ | ✓ | ✓ | . | ||
| Дизайн, ориентированный на человека (Международная организация по стандартизации, 2010 г.) | ✓ | ✓ | ✓ | ✓ |
0967| . | Общий . | Анализ . | Дизайн . | Оценка . | ||
|---|---|---|---|---|---|---|
| Cherns’ (1976) and Cherns (1987) principles | ✓✓ | |||||
| Clegg’s (2000) principles | ✓✓ | |||||
Scandinavian approaches (e. g., Bjerknes and Bratteteig, 1995) | ✓ | ✓ | ✓ | |||
| Dutch Integral Organisation Renewal (De Sitter et al., 1997) | ✓ | ✓ | ✓ | |||
| этика (Mumford, 1983, 1995) | ✓ | ✓ Socdest Alsemser.99) | ✓✓ | |||
| Socio-technical method for designing work systems (Waterson et al., 2002) | ✓ | ✓ | ||||
| Ethnographical Workplace analysis ( Hughes et al., 1992) | ✓ | ✓ | ||||
| Contextual design (Beyer and Holtzblatt, 1999) | ✓ | ✓✓ | ✓ | |||
| Cognitive systems engineering (Hollnagel and Woods, 2005) | ✓ | ✓✓ | ✓ | ✓ | ||
| Human-centred design (International Standards Organisation, 2010) | ✓ | ✓ | ✓ | ✓ |
. | Общий . | Анализ . | Дизайн . | Оценка . |
|---|---|---|---|---|
| Cherns’ (1976) and Cherns (1987) principles | ✓✓ | |||
| Clegg’s (2000) principles | ✓✓ | |||
| Скандинавские подходы (например, Bjerknes and Bratteteig, 1995) | ✓ | ✓ | ✓ | |
| Dutch Integral Organisation Renewal (De Sitter et al., 1997) | ✓ | ✓ | ✓ | |
| ETHICS (Mumford, 1983, 1995) | ✓ | ✓✓ | ✓ | ✓ |
| ✓ | ✓ | |||
| Ethnographical Workplace analysis (Hughes et al., 1992) | ✓ | ✓ | ||
| Contextual design (Beyer and Holtzblatt, 1999) | ✓ | ✓ | ✓ | . |
| Дизайн, ориентированный на человека (Международная организация по стандартизации, 2010 г.) | ✓ | ✓ | ✓ | ✓ |
0967
Это может помочь объяснить несколько разрозненный характер литературы (например, Griffiths and Dougherty, 2001).
Некоторые склонны разлагать систему на отдельные социальные и технические системы. Затем глубине анализа каждой из (под)систем уделяется разное внимание, при этом основное внимание часто уделяется техническим аспектам системы (Eason, 2001).
Такие подходы, как контекстное проектирование, в первую очередь ориентированы на использование STSD как средства построения систем, обеспечивающих более эффективную организационную поддержку.
4 Отсутствие согласованных критериев успеха
У каждой категории заинтересованных сторон может быть своя точка зрения на систему и разные критерии успеха.
процесс проектирования. Другими словами, они использовались для критики существующих систем, которые (возможно) потерпели неудачу, но не всегда предлагали, как можно решить проблемы путем соответствующей реорганизации системы (например, см. Kawka and Kirchsteiger, 19).99). Существует не так много зарегистрированных примеров успешного использования этих идей в перспективе, особенно для первого экземпляра системы нового типа. Это может быть связано с проблемой воображаемого мира (Woods and Dekker, 2000), которая возникает из-за сложности воображения или предсказания отношений между людьми, технологиями и контекстом в области, которой еще не существует.
На более низком уровне работа над паттернами кооперативного взаимодействия (Martin and Sommerville, 2004) предлагает способ поддержки повторного использования идей, полученных в ходе предыдущих полевых исследований, при проектировании новой системы.
Их аргумент состоит в том, что часть работы, проводимой этнографами и теми, кто занимается контекстуальными исследованиями, не заходит достаточно далеко, потому что она, по сути, останавливается после сбора данных, а не анализирует данные, чтобы придать им значение, чтобы их можно было более легко использовать. другими. Это нашло отражение в отчете о сотрудничестве между инженерами-программистами и социологами, в котором было обнаружено, что различия как в языке, так и в культуре являются основными препятствиями для междисциплинарной работы (Sommerville et al., 19).92).
Это было только в 19Однако в 80-х годах человеко-компьютерная инфраструктура получила широкое признание как отдельная дисциплина с присущим ей акцентом на важности взаимодействия между людьми и технологиями на самом низком уровне, а не только на дизайне пользовательского интерфейса. Он прямо признал важность роли социальных и технических аспектов работы. Однако многие подходы STSD не учитывают работу в HCI и, следовательно, мало что могут сказать о дизайне взаимодействия.
д. (Damodoran, 1996; Scacchi , 2004). В более общем плане для полевых работ возникают проблемы с определением заинтересованных сторон системы в первую очередь, прежде чем решить, какие группы заинтересованных сторон (и какие лица) должны быть вовлечены. Традиционные подходы с участием встроенного этнографа являются дорогостоящими и длительными, хотя такие понятия, как «быстрая и грязная» этнография, в некоторой степени решают эту проблему (Crabtree, 2003).
Ни одна из них не является непреодолимой, хотя решение некоторых проблем, таких как отсутствие согласованных критериев успеха (раздел 4.4), появится только по мере того, как люди будут применять эту структуру. Мы использовали проблемы для информирования о требованиях к дисциплине социотехнической системной инженерии, которую мы опишем далее.
Следствием этого являются нестабильные требования, плохой дизайн систем и неэффективные и неэффективные пользовательские интерфейсы. Все это приводит к изменениям во время разработки, что приводит к задержкам в доставке системы и к тому, что готовая система не отражает способы работы различных заинтересованных сторон.
цикл. Наше видение состоит в том, чтобы дисциплина сочетала в себе философию подходов STSD с дополнительными методами, указанными в разделе 3. STSE должен быть основан на признанных сильных сторонах социотехнических подходов, но также должен решать признанные проблемы существующих подходов (см. раздел 4). Кроме того, мы должны учитывать барьеры для внедрения любого нового подхода, а именно:
Мы не делаем предположений о технологиях, используемых для разработки системы, но отмечаем, что все чаще такие системы создаются путем настройки готовых ERP-систем, таких как предоставляемые SAP (Pollock and Williams, 2009).). В настоящее время новые системы редко бывают совершенно новыми, вместо этого они включают в себя широкий спектр существующих систем и взаимодействуют с ними. Затраты на интеграцию, вероятно, превысят затраты на разработку новых компонентов системы (Hopkins and Jenkins, 2008).
быть изученным. Таким образом, мы считаем, что можем помочь системным инженерам лучше осознать полезность социальных наук и, следовательно, сделать их более восприимчивыми к социотехническим идеям.
Обычно этому предшествует некоторый анализ, но это редко бывает углубленным анализом областей организации, где будет использоваться система.
Затем это вводится на этапе построения с помощью строго контролируемого механизма управления изменениями для обратной связи на этапе анализа. Напротив, подходы гибкой разработки чередуют анализ и построение с неформальными требованиями, используемыми для управления построением системы.
Скорее всего, будет нежелание инвестировать в понимание существующих процессов и их соответствия организации, потому что эти процессы считаются устаревшими и должны быть заменены.
Segarra, 1999). . Существуют отдельные группы инженеров по изменениям и системной инженерии, при этом основным средством коммуникации между ними является документ с требованиями или набор рабочих процессов. Те, кто участвует в процессе изменений, могут не знать о технических факторах, которые ограничивают гибкость разрабатываемой системы. Те, кто участвует в процессе разработки, могут не иметь реального представления о том, как предлагаемые рабочие процессы будут реализовываться на практике, а также о среде, в которой будет развернута система.