Корпоративные информационные системы: что нужно знать не-компьютерщикам
Темы небольшого тьюториала для некомпьютерщиков -- что им нужно знать, когда им предлагают потратить деньги на "информационные технологии":
1. Нет такой отрасли "информационные технологии". Все профи работают не в специализированных предприятиях (как обувщики или автомобилестроители), а в обычных компаниях. Не нужно сгонять всех профессионалов-компьютерщиков в один "отдел айтишников", ибо не сгоняют же менеджеров в один "менеджерский отдел"? Нельзя также обращаться к любому айтишнику с любой просьбой (например, к сисадмину -- "выбери и прикупи софт для инженеров, бухгалтеров и т.д., а затем настрой его"), можно попасть в ту же неудобную ситуацию, когда гинеколога просят запломбировать небольшую дырочку в зубе, и для этого принести все свои инструменты -- ведь он же "из врачей"! Айтишники -- это сисадмины (хотя некоторые из них могут быть с высшим образованием). Подчинение сисадминов -- АХО, как и людей, ответственных за кондиционеры и водопровод. Хороший айтишник (сисадмин), это тот, который пьёт пиво на рабочем месте, играет в игры и хвастается тем, что он параноик. А если он не пьёт пиво, а мечется по офису, то что-то тут не так. И если он пишет программы -- то тут тоже что-то не так.
2. Реальные учебные предметы компьютерщиков -- computer science, программная инженерия, информационные системы (чаще всего для "менеджмента" -- MIS), компьютерная инженерия, ну, и "информационные технологии" (с ITIL и организацией help desk) -- http://ailev.livejournal.com/472074.html. Хорошее образование в computer science не гарантирует подготовки в программной инженерии (впрочем, и наоборот), и во всех остальных компьютерных предметах. Программирование в малом vs программирования в большом. Из всего этого компьютерного месива должны интересовать управленческие информационные системы, ибо в них приходится разбираться с организационными задачами, и работать с с базами данных (а не разрабатывать программы). Выпускников "бизнес-информатики" нельзя считать подготовленными в этой области специалистами, ибо сумма знаний по менеджменту, экономике и computer science не даёт профессионализма в MIS.
3. В компаниях важны не программы, важны данные. Над одними и теми же данными работают самые разные программы. "Приложение" обычно -- это код плюс база данных. Не проблема поменять код, проблема поменять данные. Модель организации -- она в данных, а не в коде. Главные специалисты -- это специалисты по данным, а не по программам. Главные деньги должны уходить на качественные данные, а не на хитрые программы.
4. Greenfield компьютеризация по факту закончилась, все сотрудники приходят со своими ноутбуками, и у них на третий день уже больше программ и данных, чем может себе представить еще ненанятый "главный айтишник". По факту всегда brownfield. Что еще хуже, так это полная смена технологии каждые несколько лет. Телевизор сегодня -- это тоже компьютер, Samsung отгрузил за последний год два миллиона приложений для телевизоров (http://www.homemediamagazine.com/downloads/samsung-apps-hits-2-million-downloads-21745). [и тут нужно бы еще рассказать про облака, SaaS, PaaS, но времени за 5 часов не хватило -- да и не с нашими линиями связи об этом мечтать, даже в Москве]
5. Ответ на вопрос, "кто выбирает софт" во взгляде на данные (кто что видит -- смысл, значение в предметной области, или символьные строчки для преобразований):
а) Смысл (определяется контекстом, ситуацией): праксеология, деятельность, целеполагание -- люди, непосредственно занимающиеся продвижением по жизненному циклу целевых систем организации. Эти люди не могут выбирать приложения, но они знают, чего хотят. Цифирька в отчёте означает для них или премию, или невыплату зарплаты, бум или крах.
б) Значения: инфология, сведения, информация, семантика, онтология, схемы данных -- занимаются люди неопределённой специальности (эксперты, аналитики, специалисты и т.д. -- но они уже не "айтишники", но и не "не-айтишники"). Таких людей сейчас практически не учат, они как-то самообразовываются. Могут разобраться в ситуации "бизнесОв", и понимают, как разговаривать с программистами и сисадминами. Бумага у них разлинована и проименована: каждая цифирька в отчете имеет наименование, допустимые границы, известных потребителей -- но по факту они занимаются не самими этими цифрами, а "разлиновкой бумаги, на которой будут цифры, названиями граф таблицы". Вот они и должны принимать решения по приложениям, разбираясь с тем, какие данные нужны людям -- все эти CAD/EAM/CRM/ERP и т.д..
в) Символы: данные, даталогия -- занимаются программисты. Бумага разлинована в клеточку или линейку, никаких надписей и граф (т.е. неважны не только цифры в таблице, но и заголовки ее полей). Такая бумага, стерпит всё, поэтому любимое слово -- "любой" ("любая ваша информация, любая структура данных, любая обработка"), и этому слову ни в коем случае нельзя верить. Зато все преобразования символов будут выполнены, переданы в нужные места, выведены на экран, сохранены в бэкапе, переведены из одной кодировки в другую. Эти люди не могут выбирать приложения, ежели эти приложения не для них самих (например, программа бэкапа, или IDE языка программирования). Администратор баз данных -- он на границе между (б) и (в).
6. Ответ на вопрос, "как выбирать софт":
а) знать, какая у людей работа, и какие данные им нужны (что они готовы дать, что ожидают получить).
б) выразить всё нужное как "сервисы" (не задумываясь над тем, какие системы делают эти сервисы) -- функции, которые гарантированно доступны и известны. Не поддаваться провокации поставщиков программных продуктов, говорить о "сервисах" как о софте. Это не софт (компоненты программ из прайс-листа), это сервисы. Группы каких-то сервисов можно называть ERP, EAM, CAD, PLM, но очень чётко понимая, что это ни в коем случае не "линейка продуктов", поэтому лучше говорить не в этих терминах, а "планирование проектов", "планирование закупки комплектующих" и т.д. -- доводя до описания данных.
в) обсуждать, какие компоненты каких вендоров помогут реализовать сервисы. Не поддерживать прямой разговор о поддержке программными компонентами деятельности людей впрямую (вам тут же впарят всю "линию наших продуктов") -- только через "сервисы" и в сравнении с компонентами других поставщиков.
7. Главная проблема -- интеграция данных. Интеграции данных всегда нет, и не только между разными поставщиками, но и внутри "линии наших продуктов" одного поставщика. Поставщики тут обычно врут во всех своих рекламных заявлениях. Интеграция данных с де-факто всегда существующими данными предприятия (помним про brownfield) обычно делается существенной перепиской схемы базы данных с последующей перепиской кусков софта -- в объемах, иногда сравнимых с разработкой продукта полностью под заказ "с нуля" (это называются "настройкой" -- скрывая масштабы бедствия. Объем "настройки" в деньгах часто -- столько же, сколько стоит сам дорогущий софт. И это будет только "первая серия" настройки, которая потом превращается в мыльную оперу и "бесконечно вкусный апельсин" для компании-интегратора).
8. В интеграции данных нужно сразу понимать, что есть SOA -- общее для всего предприятия решение по конвертации форматов данных, транспорту данных, вводу паролей для всех приложений и всех прочих функций. Главное слово -- "шина предприятия", от электрических шин (толстых медных полосок, в которые втыкаются все остальные мелкие и круупные проводочки). Моды и повертия: SOA -- это мода, а не поветрие.
9. MDM (НСИ -- думать про "все заголовки во всех таблицах всех отчётов", "классификаторы", "адресные базы") и "вынос НСИ из приложений" -- это есть хорошо, это нужно делать в комплекте с SOA. Проблемы масштаба: слишком много разных видов данных -- "что для одного приложения атрибут, то для другого объект, и наоборот", "3D будем хранить как файл, а перекодируют пусть сами приложения" и т.д.. Объект-ориентированное представление данных против факт-ориентированного представления.
10. Факт-ориентированные (т.е. гарантированно всеядные, пополняемые) справочные данные вне пределов предприятия -- национальные, отраслевые, "холдинговые", "корпоративные" RDL. Интеграция данных по технологии ISO 15926.
11. Краткие характеристики некоторых видов приложений:
а) САПР и PLM -- фиктивность буковки "А" в слове САПР, "все CAD/CAM втыкаются в PLM". Начинать (помним brownfield! это "начало" -- всегда продолжение!) нужно всегда с PLM, чтобы САПРам было куда втыкаться.
б) ERP -- в основе программа планирования потока деталей, собирающихся в готовые изделия в крупных производствах. Алгоритмы планирования (MRP, MRP II, APS), "ERP-шовинизм" (все типы программ объявляются "входящими в нашу ERP"). MES как менее шовинистический вариант ERP уровня цеха.
в) EAM -- удобная система инвентаризции, близка к ERP по склонности к шовинизму.
г) O&M -- что где как функционирует, что где когда ломалось, что нужно чинить и менять.
...
12. По идее, нужно дальше было обсуждать документооборот и issue trackers, ECM, CRM и огромное число других классов софта. Потом -- рассказать про свободный софт, открытый софт, аутсорсинг, системную интеграцию и прочие бизнес-модели. Потом -- про управление корпоративными информационными системами в больших холдингах путем профилирования стандартов. Но -- была уже пятница вечер, и обо всём этом я расскажу когда-нибудь в другой раз.
Disclaimer. То, что я рассказываю, может вызвать серьезные протесты у некоторых "профессиональных айтишников". А то, что я тут написал наверняка вызовет протесты, ибо из 5 часов (сегодняшний опыт рассказа по этим тезисам) в текст попали лишь несколько жестких формулировок, без оговорок и разъяснений, и даже без существенно проясняющих диаграмм на флипчарте. И вряд ли в комментах я что-нибудь наразъясняю в объеме пяти часов с картинками, да и вряд ли соглашусь с тем, что "автор дилетант, и ничего в корпоративном айти не понимает". Вы предупреждены.
Видео нет, это клиентские мероприятия.
1. Нет такой отрасли "информационные технологии". Все профи работают не в специализированных предприятиях (как обувщики или автомобилестроители), а в обычных компаниях. Не нужно сгонять всех профессионалов-компьютерщиков в один "отдел айтишников", ибо не сгоняют же менеджеров в один "менеджерский отдел"? Нельзя также обращаться к любому айтишнику с любой просьбой (например, к сисадмину -- "выбери и прикупи софт для инженеров, бухгалтеров и т.д., а затем настрой его"), можно попасть в ту же неудобную ситуацию, когда гинеколога просят запломбировать небольшую дырочку в зубе, и для этого принести все свои инструменты -- ведь он же "из врачей"! Айтишники -- это сисадмины (хотя некоторые из них могут быть с высшим образованием). Подчинение сисадминов -- АХО, как и людей, ответственных за кондиционеры и водопровод. Хороший айтишник (сисадмин), это тот, который пьёт пиво на рабочем месте, играет в игры и хвастается тем, что он параноик. А если он не пьёт пиво, а мечется по офису, то что-то тут не так. И если он пишет программы -- то тут тоже что-то не так.
2. Реальные учебные предметы компьютерщиков -- computer science, программная инженерия, информационные системы (чаще всего для "менеджмента" -- MIS), компьютерная инженерия, ну, и "информационные технологии" (с ITIL и организацией help desk) -- http://ailev.livejournal.com/472074.html. Хорошее образование в computer science не гарантирует подготовки в программной инженерии (впрочем, и наоборот), и во всех остальных компьютерных предметах. Программирование в малом vs программирования в большом. Из всего этого компьютерного месива должны интересовать управленческие информационные системы, ибо в них приходится разбираться с организационными задачами, и работать с с базами данных (а не разрабатывать программы). Выпускников "бизнес-информатики" нельзя считать подготовленными в этой области специалистами, ибо сумма знаний по менеджменту, экономике и computer science не даёт профессионализма в MIS.
3. В компаниях важны не программы, важны данные. Над одними и теми же данными работают самые разные программы. "Приложение" обычно -- это код плюс база данных. Не проблема поменять код, проблема поменять данные. Модель организации -- она в данных, а не в коде. Главные специалисты -- это специалисты по данным, а не по программам. Главные деньги должны уходить на качественные данные, а не на хитрые программы.
4. Greenfield компьютеризация по факту закончилась, все сотрудники приходят со своими ноутбуками, и у них на третий день уже больше программ и данных, чем может себе представить еще ненанятый "главный айтишник". По факту всегда brownfield. Что еще хуже, так это полная смена технологии каждые несколько лет. Телевизор сегодня -- это тоже компьютер, Samsung отгрузил за последний год два миллиона приложений для телевизоров (http://www.homemediamagazine.com/downloads/samsung-apps-hits-2-million-downloads-21745). [и тут нужно бы еще рассказать про облака, SaaS, PaaS, но времени за 5 часов не хватило -- да и не с нашими линиями связи об этом мечтать, даже в Москве]
5. Ответ на вопрос, "кто выбирает софт" во взгляде на данные (кто что видит -- смысл, значение в предметной области, или символьные строчки для преобразований):
а) Смысл (определяется контекстом, ситуацией): праксеология, деятельность, целеполагание -- люди, непосредственно занимающиеся продвижением по жизненному циклу целевых систем организации. Эти люди не могут выбирать приложения, но они знают, чего хотят. Цифирька в отчёте означает для них или премию, или невыплату зарплаты, бум или крах.
б) Значения: инфология, сведения, информация, семантика, онтология, схемы данных -- занимаются люди неопределённой специальности (эксперты, аналитики, специалисты и т.д. -- но они уже не "айтишники", но и не "не-айтишники"). Таких людей сейчас практически не учат, они как-то самообразовываются. Могут разобраться в ситуации "бизнесОв", и понимают, как разговаривать с программистами и сисадминами. Бумага у них разлинована и проименована: каждая цифирька в отчете имеет наименование, допустимые границы, известных потребителей -- но по факту они занимаются не самими этими цифрами, а "разлиновкой бумаги, на которой будут цифры, названиями граф таблицы". Вот они и должны принимать решения по приложениям, разбираясь с тем, какие данные нужны людям -- все эти CAD/EAM/CRM/ERP и т.д..
в) Символы: данные, даталогия -- занимаются программисты. Бумага разлинована в клеточку или линейку, никаких надписей и граф (т.е. неважны не только цифры в таблице, но и заголовки ее полей). Такая бумага, стерпит всё, поэтому любимое слово -- "любой" ("любая ваша информация, любая структура данных, любая обработка"), и этому слову ни в коем случае нельзя верить. Зато все преобразования символов будут выполнены, переданы в нужные места, выведены на экран, сохранены в бэкапе, переведены из одной кодировки в другую. Эти люди не могут выбирать приложения, ежели эти приложения не для них самих (например, программа бэкапа, или IDE языка программирования). Администратор баз данных -- он на границе между (б) и (в).
6. Ответ на вопрос, "как выбирать софт":
а) знать, какая у людей работа, и какие данные им нужны (что они готовы дать, что ожидают получить).
б) выразить всё нужное как "сервисы" (не задумываясь над тем, какие системы делают эти сервисы) -- функции, которые гарантированно доступны и известны. Не поддаваться провокации поставщиков программных продуктов, говорить о "сервисах" как о софте. Это не софт (компоненты программ из прайс-листа), это сервисы. Группы каких-то сервисов можно называть ERP, EAM, CAD, PLM, но очень чётко понимая, что это ни в коем случае не "линейка продуктов", поэтому лучше говорить не в этих терминах, а "планирование проектов", "планирование закупки комплектующих" и т.д. -- доводя до описания данных.
в) обсуждать, какие компоненты каких вендоров помогут реализовать сервисы. Не поддерживать прямой разговор о поддержке программными компонентами деятельности людей впрямую (вам тут же впарят всю "линию наших продуктов") -- только через "сервисы" и в сравнении с компонентами других поставщиков.
7. Главная проблема -- интеграция данных. Интеграции данных всегда нет, и не только между разными поставщиками, но и внутри "линии наших продуктов" одного поставщика. Поставщики тут обычно врут во всех своих рекламных заявлениях. Интеграция данных с де-факто всегда существующими данными предприятия (помним про brownfield) обычно делается существенной перепиской схемы базы данных с последующей перепиской кусков софта -- в объемах, иногда сравнимых с разработкой продукта полностью под заказ "с нуля" (это называются "настройкой" -- скрывая масштабы бедствия. Объем "настройки" в деньгах часто -- столько же, сколько стоит сам дорогущий софт. И это будет только "первая серия" настройки, которая потом превращается в мыльную оперу и "бесконечно вкусный апельсин" для компании-интегратора).
8. В интеграции данных нужно сразу понимать, что есть SOA -- общее для всего предприятия решение по конвертации форматов данных, транспорту данных, вводу паролей для всех приложений и всех прочих функций. Главное слово -- "шина предприятия", от электрических шин (толстых медных полосок, в которые втыкаются все остальные мелкие и круупные проводочки). Моды и повертия: SOA -- это мода, а не поветрие.
9. MDM (НСИ -- думать про "все заголовки во всех таблицах всех отчётов", "классификаторы", "адресные базы") и "вынос НСИ из приложений" -- это есть хорошо, это нужно делать в комплекте с SOA. Проблемы масштаба: слишком много разных видов данных -- "что для одного приложения атрибут, то для другого объект, и наоборот", "3D будем хранить как файл, а перекодируют пусть сами приложения" и т.д.. Объект-ориентированное представление данных против факт-ориентированного представления.
10. Факт-ориентированные (т.е. гарантированно всеядные, пополняемые) справочные данные вне пределов предприятия -- национальные, отраслевые, "холдинговые", "корпоративные" RDL. Интеграция данных по технологии ISO 15926.
11. Краткие характеристики некоторых видов приложений:
а) САПР и PLM -- фиктивность буковки "А" в слове САПР, "все CAD/CAM втыкаются в PLM". Начинать (помним brownfield! это "начало" -- всегда продолжение!) нужно всегда с PLM, чтобы САПРам было куда втыкаться.
б) ERP -- в основе программа планирования потока деталей, собирающихся в готовые изделия в крупных производствах. Алгоритмы планирования (MRP, MRP II, APS), "ERP-шовинизм" (все типы программ объявляются "входящими в нашу ERP"). MES как менее шовинистический вариант ERP уровня цеха.
в) EAM -- удобная система инвентаризции, близка к ERP по склонности к шовинизму.
г) O&M -- что где как функционирует, что где когда ломалось, что нужно чинить и менять.
...
12. По идее, нужно дальше было обсуждать документооборот и issue trackers, ECM, CRM и огромное число других классов софта. Потом -- рассказать про свободный софт, открытый софт, аутсорсинг, системную интеграцию и прочие бизнес-модели. Потом -- про управление корпоративными информационными системами в больших холдингах путем профилирования стандартов. Но -- была уже пятница вечер, и обо всём этом я расскажу когда-нибудь в другой раз.
Disclaimer. То, что я рассказываю, может вызвать серьезные протесты у некоторых "профессиональных айтишников". А то, что я тут написал наверняка вызовет протесты, ибо из 5 часов (сегодняшний опыт рассказа по этим тезисам) в текст попали лишь несколько жестких формулировок, без оговорок и разъяснений, и даже без существенно проясняющих диаграмм на флипчарте. И вряд ли в комментах я что-нибудь наразъясняю в объеме пяти часов с картинками, да и вряд ли соглашусь с тем, что "автор дилетант, и ничего в корпоративном айти не понимает". Вы предупреждены.
Видео нет, это клиентские мероприятия.