Menu
PRODUCT INTEGRITY

A FEATURE IS EASY TO SHOW.
LOGIC IS HARDER TO FAKE.

สร้างระบบได้ ≠ เข้าใจขอบเขตของระบบ

Before the architecture

SAME SHAPE. DIFFERENT DEPTH.

การเห็นโครงสร้างของระบบ ไม่เหมือนกับการเข้าใจสิ่งที่ทำให้ระบบนั้นทำงาน
ภายใต้ Architecture ที่ดูคล้ายกัน อาจมี Logic ภายในแตกต่างกันอย่างมาก
01
SEE THE OUTPUT Result-oriented view
General Logic Domain Logic Interlock Logic
Dashboard OUTPUT ACHIEVED
INTERNAL LOGIC NOT EXPOSED
What is visible The result can be seen. The logic remains opaque.
02
UNDERSTAND THE SYSTEM Traceable internal logic
Permission
Workflow
Assignment
Review
Approval
Notify
Version
Audit
Dashboard
State
Requirement
Data
Owner
Evidence
Rule
Calculation
Monitoring
Disclosure
Dependency
Relationship
Reuse
Impact
Propagation
General Logic Domain Logic Interlock Logic
Inside the system Select an output to trace the logic behind it.
VS
Product Integrity
Producing the output is one thing. Knowing why the output is correct is another.
Hover or tap an output to explore
PRODUCT INTEGRITY

THE DEPTH
OF SYSTEM CAPABILITY

ความสามารถของ Software
ไม่ได้มีความลึกเท่ากัน

จากโครงสร้างพื้นฐานที่พบได้ทั่วไป ไปจนถึง Logic ที่ต้องเข้าใจ Domain ความสัมพันธ์ และผลกระทบของข้อมูล

01
BROADLY AVAILABLE

GENERAL LOGIC

โครงสร้างพื้นฐานที่พบได้ทั่วไปใน Business Software

Workflow / Permission / Approval / Dashboard
02
DOMAIN SPECIFIC

DOMAIN LOGIC

เริ่มต้องเข้าใจกฎ โครงสร้าง และวิธีทำงานเฉพาะของ Domain

03
DEEP SYSTEM LOGIC

INTERLOCK LOGIC

จัดการ Dependency, Reuse และ Impact ระหว่างข้อมูลและ Process

CAPABILITY DEPTH
↓
SYSTEM BOUNDARY
04
HUMAN JUDGMENT

ระบบสนับสนุน
มนุษย์รับผิดชอบการตัดสินใจ

เมื่อการตัดสินใจต้องอาศัยบริบท ความรับผิดชอบ หรือ Professional Judgment Capability ของระบบไม่ควรถูกตีความว่าเป็น Authority

THE PRINCIPLE
FEATURE บอกว่าระบบมีอะไร
LOGIC บอกว่าระบบทำงานอย่างไร
BOUNDARY บอกว่าระบบไปได้ถึงไหน
GENERAL LOGIC× DOMAIN LOGIC× INTERLOCK LOGIC× BOUNDARY× HUMAN JUDGMENT× GENERAL LOGIC× DOMAIN LOGIC× INTERLOCK LOGIC× BOUNDARY× HUMAN JUDGMENT×
01
GENERAL LOGIC

โครงสร้างพื้นฐาน
ของการทำงาน

General Logic คือความสามารถพื้นฐาน ที่สามารถใช้ร่วมกันได้ในหลาย Business Process

User & Permission Workflow Assignment Review & Approval Notification Version Control Audit Trail Dashboard

องค์ประกอบเหล่านี้ทำให้ระบบสามารถจัดการ กระบวนการทำงานได้อย่างเป็นระบบ

แต่การมี General Logic เพียงอย่างเดียว ยังไม่ได้หมายความว่าระบบเข้าใจกฎ โครงสร้างข้อมูล หรือบริบทเฉพาะของงานนั้น

General Logic ช่วยบริหาร Process
01 GENERAL LOGIC
General Logic
02
DOMAIN LOGIC

Logic ที่ออกแบบตาม
ลักษณะเฉพาะของงาน

แต่ละ Domain มีโครงสร้างข้อมูล กฎ และความสัมพันธ์ที่แตกต่างกัน
ESG
Requirement → Data → Owner → Evidence → Disclosure
RISK
Risk → Cause → Control → Action → Monitoring
CARBON
Activity Data → Emission Factor → Calculation → Inventory
Domain Logic
DOMAIN LOGIC
UI อาจดูคล้ายกัน
แต่ Logic ภายใน
อาจเป็นคนละระบบ

แม้ User Interface อาจมีลักษณะคล้ายกัน แต่ Business Logic ภายใน อาจแตกต่างกันอย่างมีนัยสำคัญ

Domain Logic ทำให้ระบบไม่ได้เพียงจัด Workflow แต่สามารถทำงานตามกฎ โครงสร้าง และความสัมพันธ์ของ Domain นั้นได้
03
INTERLOCK LOGIC

เมื่อข้อมูลหนึ่งส่วน
ไม่ได้จบอยู่ที่ Process เดียว

ในองค์กรจริง ข้อมูล ข้อกำหนด และกระบวนการไม่ได้ทำงานแยกจากกัน

01 ข้อมูลหนึ่งชุดอาจรองรับหลาย Requirement
02 Evidence หนึ่งรายการอาจเกี่ยวข้องกับหลาย Process
03 Risk หนึ่งเรื่องอาจส่งผลต่อหลาย ESG Topic
04 Metric เดียวกันอาจถูกใช้ใน Target, Monitoring และ Disclosure
DEPENDENCY RELATIONSHIP REUSE IMPACT

Interlock Logic ทำให้ข้อมูลสามารถถูกเชื่อม ใช้ซ้ำ และสะท้อนผลกระทบไปยังส่วนอื่นของระบบได้

เมื่อข้อมูลหรือข้อกำหนดหนึ่งเปลี่ยน องค์กรจึงสามารถมองเห็นสิ่งที่เกี่ยวข้อง และผลกระทบที่ตามมาได้ชัดเจนขึ้น

ไม่ใช่เพียงเก็บความสัมพันธ์ไว้ แต่ทำให้ความสัมพันธ์นั้นทำงานได้
Interlock Logic
INTERLOCK DATA × REQUIREMENT × PROCESS
04
HUMAN JUDGMENT

ระบบต้องรู้ว่า
จุดไหนควรหยุดให้คนตัดสิน

Human Judgment
Technology
สนับสนุนการตัดสินใจ ไม่จำเป็นต้องแทนที่มัน

Software สามารถรวบรวม ตรวจสอบ คำนวณ เชื่อมโยง แจ้งเตือน วิเคราะห์ และเสนอทางเลือกได้

แต่บางเรื่องยังต้องอาศัยบริบท ความรับผิดชอบ และ Professional Judgment

  • การตีความ Requirement
  • การประเมินความเพียงพอของ Evidence
  • Materiality Assessment
  • Risk Judgment
  • การตัดสินใจเชิงกลยุทธ์
THE DESIGN QUESTION ระบบควรตัดสินอะไร ควรเสนออะไร และอะไรต้องได้รับการรับรองจากมนุษย์
Human Judgment คือ Boundary หนึ่งของ System Design
Explore Governed Intelligence ↗
WHY IT MATTERS

คำว่า
“รองรับ”
อาจมีความหมาย
ไม่เท่ากัน

01
รองรับการจัดเก็บ Document / Evidence
02
รองรับกระบวนการ Workflow / Assignment / Approval
03
รองรับ Domain Rule / Calculation / Domain Structure
04
รองรับความสัมพันธ์ Dependency / Reuse / Impact
A BETTER QUESTION

เมื่อ Software ระบุว่า “รองรับ”
มันรองรับในระดับใด?

System Capability Depth
SUPPORTED ≠ UNDERSTOOD
OUR PRODUCT INTEGRITY

Capability ที่ดี
ต้องอธิบาย Boundary ได้

Product Integrity Specification
01

Capability
is not Compliance

Software สามารถสนับสนุนกระบวนการ Compliance ได้ แต่ Compliance ยังคงเป็นผลลัพธ์จาก Process, Evidence และ Governance ขององค์กร

02

Workflow
is not Domain Logic

การมี Workflow ไม่ได้หมายความว่า Software รองรับกฎ โครงสร้างข้อมูล และความสัมพันธ์เฉพาะของ Domain นั้นแล้ว

03

Automation
is not Authority

ระบบอาจวิเคราะห์ เสนอ หรือดำเนินการบางอย่างโดยอัตโนมัติได้ แต่ความสามารถในการ Automation ไม่ได้หมายความว่าระบบควรมีอำนาจตัดสินทุกเรื่อง

04

Boundary
is part of Specification

สิ่งที่ระบบทำได้ ทำไม่ได้ ทำได้ภายใต้เงื่อนไขใด และจุดใดต้องส่งต่อให้มนุษย์ ควรถูกอธิบายเป็นส่วนหนึ่งของ Specification เช่นเดียวกับ Feature และ Capability

PRODUCT INTEGRITY

Software ที่น่าเชื่อถือ
ควรอธิบาย ขอบเขตของตัวเอง ได้อย่างชัดเจน

01 ทำอะไรได้
02 ทำอย่างไร
03 ทำได้ถึงไหน
04 ภายใต้เงื่อนไขอะไร
05 ตรงไหนยังต้องมีคนรับผิดชอบการตัดสินใจ
CAPABILITY × CLARITY
ความชัดเจนของ Capability สำคัญพอ ๆ กับ Capability เอง