Интеграция c продуктами SAP

Состав "интегрируемых" программных продуктов: центр интеграции - SAP S/4HANA Cloud

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

А именно "Услуги для реализации пользовательского опыта".

Стоительные блоки интеграции.

Залог успешной коммуникации

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

• Чтобы научиться хорошо говорить и доносить до Собеседника нужную информацию - нужно сначала научиться слушать.
• Подобное притягивает подобное.
• Говорить надо не так, как нам удобно говорить, а так, как слушателям удобно воспринимать. Если ваша речь содержательна, ясна и доходчива; если у вас поставленный голос, четкая дикция, выразительная интонация и эмоциональная окраска, органичные жесты; если вы проявляете и контролируете признаки уверенности - то это значит, что ваша публичная речь более влиятельна, чем та, в которой эти элементы хромают. 
• Слово "нет" - пощечина собеседнику - гласит еще одно правило практической психологии общения. Думаю, что когда люди придумывали поговорку о том, что слово - не воробей…, то при этом, скорее всего, имели в виду именно слово "нет" (в смысле противоречия оппоненту).
• Наши оценки предметов больше характеризуют нас, чем сами предметы. Поэтому справедливо мнение, что судить о человеке в большей степени можно не по тому, что о нем говорят другие, а по тому, что он говорит о других.
• Не давайте советов другим, когда вас об этом не просят.
• НАШИ ОЦЕНКИ СОБЫТИЙ ХАРАКТЕРИЗУЮТ НАС, А НЕ СОБЫТИЯ.

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

Дата	Время
Номер телефона	Организация
Фамилия, имя, отчество абонента
Записываются заранее		Записываются по ходу беседы
Вопросы	Прогнозируемые ответы	Ответы
1	1	1
2	2	2
3	3	3
Выводы: (достигнутый результат, полученные сведения, дальнейшие действия и т. д.)
Исполнитель:

Рациональная композиция делового разговора - «Семь П»:

·П1. Приветствие.

·П2. Представление.

·П3. Причина (объяснение цели звонка).

·П4. Проблема (обсуждение вопроса).

·П5. Подведение итогов обсуждения.

·П6. Признательность: выражение благодарности.

·П7. Прощание.

Источник. М.А.Измайлова. Навыки ведения эффективного делового разговора по телефону.

Абстракция истинности программного кода

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

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

Уточним некоторые вопросы формализованного рассмотрения правильности работы программ.

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

Пусть O₁ - объект, который необходимо отразить в объекте O₂.
Требуется построить соответствие

F: O₁->O₂, 

обеспечивающие реализацию объекта O₂, отвечающего целям и замыслу ИС,

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

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

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

Рассмотрим четыре сущности:

• O₁-объект;
• O₂-объект;
• F-соответствие;
• цели функционирования информационной системы.

Что такое цель функционирования системы?

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

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

Примечание. Мы подразумеваем следующие этапы жизненного цикла ИС: обследование объекта проектирования, концептуальное проектирование, реализация (программирование), тестирование, опытная эксплуатация, продуктивная эксплуатация.

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

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

Выделим три категории специалистов:

• дизайнер решения (он же архитектор. он же методолог, он же консультант),
• программист,
• пользователь.

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

Опишем функции данных специалистов:

• дизайнер решения - построение феноменологического описания системы, концептульное и логическое проектирования структуры ИС;
• программист - построение физической структуры ИС;
• пользователь - эксплуатация ИС.

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

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

F: O₁->O₂, 

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

Программист на основе результатов работы исследователя должен построть объект O₂. 

Пользователь работает с объектом O₂, актуализируя свойства и содержание O₂.

Можно дать также слежующую интерпретацию выше сказанного:

• дизайнер - исследует и описывает форму и содержание объекта O1;
• программист - реализует форму O₂;
• пользователь - реализует содержание O₂.

Это в свою очередь, предписывает следующие аспекты рассмотрения:

• форма и содержание O₁;
• реализацию формы O₂;
• реализацию содержания O₁.

Казалось, по подобию объекта O₂ следует рассмотреть и объект O₁. Однако это не так. Так как объект O₁ - объект действительности (реальной или мыслимой), то его форма и содержания будут неразрывно связанными, хотя мыслительными конструкциями могут рассматривать в отрыве друг от друга. Для объекта O₂ наблюдается несколько иная ситуация -  в процессе создания системы в начале появляется форма, и лишь потом, в процессе эксплуатации системы форма наполняется содержанием. Например, фреймворк можно полагать формой.
В соответствии с нормами спекулятивного мышления форма выступает как концептуально-логическая основа существования-бытия ИС, содержание - проявление конкретных форм существования. Для сложных систем, в особенности, когда знаний об объекте O₁ недостаточно, возможен подход методолического разложения объекта на "форму" и "содержание". Более того, вероятно, при отсутствии такого разложения (редукции), невозможно будет построить ИС. Если же форма и содержание наличествуют, то как для ИС, так и для объекта O₁, мы имеет наряду с процессом моделирования и процесс познания, а ИС может выступать и как познавательная система, - экспериментальная, гипотетическая, мыслимая, - но манифестирующая свое совпадение с реальной системой в моделируемых аспектах. Моделируемых, кстати, весьма ограниченно, но тем не менее - существенно.

С точки зрения дизайнера на первом этапе проектирования системы удовлетворительной целью будет сама возможность представления объекта O₁ объектом O₂. После достижения этой цели, или одновременно с ней, дизайнер как исследователь оценивается сам объект O₂, а именно, правильно ли представлен объект O₁. Дизайнера-исследователя, вообще говоря интересует только одно - как можно более полнее представить (смоделировать) объект O₁. Это позволяет, на интуитивном уровне, утверждать (дизайнеру), что изменение конечных целей системы не скажется на самой системе, а всего лишь потребует незначительной корректировки ИС.

Программиста в первую очередь будет интересовать вопрос о возможности реализации объекта O₂ инструментальными средствами (язык пограммирования, система управления базами данных, программные "заделы" - классы, стандартные программы, интерфейсы, щаблоны программирования), которые он имеет и/или которыми он умеет пользоваться. Немаловажна и аппаратная платформа - возможность с точки зрения вычислительных ресурсов реализовать объект O₂ в примлемые сроки и за приемлемые деньги. Однако сама физическая реализация объекта O₂ не достаточна. Требуется доказать, что физическая структура не отличается от замысла.

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

В качестве цели построения модели определим задачу замещения объекта O₁ на объект O₂ с целью фиксации важнейших свойств объекта O₁.

Попытаемся описать критерии, показатели эффективности построения ИС с позиции замещения одного объекта другим.

Итак, выдвинем следующие критерии построения правильности построения модели:

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

Хорошая модель может быть нестрого определена так:

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

Также имеет место и такая "развернутая оценка качества СИ.

“Качество функционирования ИС в целом оценивается по:

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

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

Перечислим основные цели и критерии построения ИС, на рассматривая состоятельность данных критериев:

1. Фиксация важнейших свойств O₁.
2. Качественная адекватность.
3. Количественная адекватность.
4. Простота.
5. Полнота или возможность получения интересующих утверждений.
6. Продуктивность или возможность получения исходных данных.
7. Устойчивость к погрешностям исходных данных.
8. Наглядность.
9. Возможность к взаимодействию, совершенствованию и развитию.
10. Надежность представления информации.
11. Правильность реализации объекта O2.
12. Своевременность получения информации.
13. Достоверность и актуальность информации.
14. Конфиденциальность информации.

Рассмотрим первых три критерия.

1. Фиксация важнейших свойств O₁.

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

• какие свойства имеются у O₁?
• все свойства объекта O₁ описаны?
• правильно ли описаны свойства объекта O₁? (данный вопрос относится к критерию 2).
• какие из свойств объекта O₁ являются важнейшими с точки зрения: дизайнера, программиста, пользователя и почему?

Ответ на вопрос почему? потребует описание критерия выбора свойств. Данный критерий может быть задан либо в виде функциональной зависимости, либо описан лингвистическими переменными (например, важно/неважно). Могут быть использованы более сложные лингвистические шкалы.

После проведения оценки тут же встает другой вопрос:

• измениться ли оценка важности в будущем, поможет ли опыт, накопленный в ходе эксплуатации, углубить знания об объекте O₁?

В этой ситуации возможны следующие исходы:

• расширится/сузится список свойств;
• измениться критерий оценки выбора свойств;
• измениться ряд предпочтений (в общем случае изменение критерия может и не привести к изменению порядка ранжирования свойств).

2. Качественная адекватность.

С точки зрения описания данного критерия требуется дать более точное, а вернее, формализованное описание адекватности. Интуитивно очевидно, что если реализован критерий 1, то в какой то степени удовлетворены критерии 2 и 3. Однако одного интуитивного описания недостаточно. Приведем графическую схему выше сказанного и перейден к более формальному описанию адекватности.

 


На пересечении строк таблицы находятся факторы, которые влияют на значение и порядок расчета критериев адекватности. Адекватность непосредственно связана с утвердительным ответом на вопрос “А правда ли что?”

Любая из систем имеет одно из следующих доминирующих функциональных свойств:

• модель структуры
• модель процедуры
• модель явления.

В независимости от модели, необходимо доказывать справедливость модели с точки зрения ответа на вопрос "А правда ли что?".

Зафиксируем набор следующих системологических факторов.
X - множество исходных данных;
C - множество параметров системы;
Z - множество воздействий среды;
U - множество управляющих воздействий (в ряде случаев может быть сведено либо к X, либо к Z, в зависимости от точки зрения исследователя);
Y - множество наблюдаемых реакций;
F - правило преобразования множества {X, C, Z, U} в F.

В общем случае имитационная модель может быть описана как

Y=F(X, C, Z, U).

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

Формилизуем вопрос "А правда ли что?". А именно, на каждом этапе жизненного цикла ИС  будут стоять вопросы:

• истинно ли X?
• истинно ли C?
• истинно ли Z?
• истинно ли U?

Но что есть истинность в применении к данным категориям?

Исследуем истинность с точки зрения решения следующих вопросов, поставленных в отношении множеств X, C, Z, U:

• истинно ли по составу (набору),
• истинно ли по структуре,
• истинно ли по значению,
• истинно ли по процедуре получения,
• истинно ли по факту отсутствия/наличия.

При этом необходимо

1. определить понятие истинности;
2. определить - существует ли процедура, доказывающая истинность;
3. является ли процедура разрешимой (вычислимой).

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

• истинно ли F?

В этом случае мы имеем сложные взаимосвязи: F является стрелкой, связывающей декартовое произведение <X,C,Z,U> и Y.

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

Истинность стрелки F опирается на истинность объектов <X,C,Z,U> и Y, однако этого недостаточно для доказательства истинности истинности самой стрелки F, более того истинность концов стрелки может ничего не определять. "Вычисление" истинности стрелки F должно производиться с точки зрения некоторой прото- (мета-) системы, а сама стрелка может быть имет значение (смысл), определяющее концептуальную основу модели.

Казалось бы, что для того чтобы доказать истинность Y достаточно доказать, что <X,C,Z,U> и F истинны.
Однако это не так, так как даже при соблюдении данных условий Y может быть ложно, если выход оценивается с позиции некоторой метатеории.
Для характеризации такой ситуации будем говорить о принципе внешнего дополнения.
При последовательном рассмотрении, можно утвержадат, что в силу ложности Y может быть пересмотрена сама процедура доказательства истинности <X,C,Z,U> и F.

В качестве примера проведения регулярного анализа приведем следующую таблицу истииности:

№	X	Z	U	C	F	Y		№	X	Z	U	C	F	Y
0	0	0	0	0	0	0		32	1	0	0	0	0	0
1	0	0	0	0	0	1		33	1	0	0	0	0	1
2	0	0	0	0	1	0		34	1	0	0	0	1	0
3	0	0	0	0	1	1		35	1	0	0	0	1	1
4	0	0	0	1	0	0		36	1	0	0	1	0	0
5	0	0	0	1	0	1		37	1	0	0	1	0	1
6	0	0	0	1	1	0		38	1	0	0	1	1	0
7	0	0	0	1	1	1		39	1	0	0	1	1	1
8	0	0	1	0	0	0		40	1	0	1	0	0	0
9	0	0	1	0	0	1		41	1	0	1	0	0	1
10	0	0	1	0	1	0		42	1	0	1	0	1	0
11	0	0	1	0	1	1		43	1	0	1	0	1	1
12	0	0	1	1	0	0		44	1	0	1	1	0	0
13	0	0	1	1	0	1		45	1	0	1	1	0	1
14	0	0	1	1	1	0		46	1	0	1	1	1	0
15	0	0	1	1	1	1		47	1	0	1	1	1	1
16	0	1	0	0	0	0		48	1	1	0	0	0	0
17	0	1	0	0	0	1		49	1	1	0	0	0	1
18	0	1	0	0	1	0		50	1	1	0	0	1	0
19	0	1	0	0	1	1		51	1	1	0	0	1	1
20	0	1	0	1	0	0		52	1	1	0	1	0	0
21	0	1	0	1	0	1		53	1	1	0	1	0	1
22	0	1	0	1	1	0		54	1	1	0	1	1	0
23	0	1	0	1	1	1		55	1	1	0	1	1	1
24	0	1	1	0	0	0		56	1	1	1	0	0	0
25	0	1	1	0	0	1		57	1	1	1	0	0	1
26	0	1	1	0	1	0		58	1	1	1	0	1	0
27	0	1	1	0	1	1		59	1	1	1	0	1	1
28	0	1	1	1	0	0		60	1	1	1	1	0	0
29	0	1	1	1	0	1		61	1	1	1	1	0	1
30	0	1	1	1	1	0		62	1	1	1	1	1	0
31	0	1	1	1	1	1		63	1	1	1	1	1	1

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

Возможно построить некоторый эксперимент и вывести пропозициональную формулу, связывающую истинность Y и X, Z, C, U, F. Если по результатам эксперимента мы имеем полную (с точки зрения декартового произведения) таблицу, то это свидетельствует о том, что построенная модель ничем ни отличается от хаотических систем, любые ее выходы “равноистинны”. Назовем такую систему “абсолютно алогичной”. При наличии же запрещенных ситуации дело упрощается. Если удается построить пропозициональную формулу с учетом всех переменных, то назовем такую систему полностью логичной. Если мы имеем некоторую формулу, в которой отсутствует зависимость истинности выхода от одного из фактора, то мы имеем не зависимую от фактора (в смысле истинности) модель, а сам фактор должен быть исключен из рассмотрения.

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

Формализуем последние утверждения:

Пусть для оценки истинности объектов X, Z, C, U, F и Y используются некоторые правила, процедуры или формулы вывода в записи

Ф_X(X), Ф_Z(Z), Ф_U(U), Ф_C(C), Ф_F(F), Ф_Y(Y).

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

Ф_Y(Y) (?=?) M(Ф_X(X), Ф_Z(Z), Ф_U(U), Ф_C(C), Ф_F(F))

Успех или неуспех в построении формулы предполагает интерпретацию равенства или неравенства или анализ причин неразрешимости. Возможно, удается получить некоторый ответ для подмножеств и если мощность данных подмножеств достаточна с точки зрения практики, то можно перейти к следующему этапу - детальному анализу состава и структуры X, Z, C, U, F.

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

Однако, построение пропозициональной формулы не единственное приложение данной формализации.

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

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

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

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