비즈니스 규칙이 먼저 온다

최근 동료들과 저는 대규모 고객 조직의 수석 소프트웨어 개발자에게 그곳에서 중요한 재엔지니어링 노력에 대한 진행 상황에 대해 이야기하고있었습니다. 우리의 관심사는 프로젝트 팀 구성원이 대규모 프로토 타입을 제공하기 위해 약 9 개월 기한을 맞출 수 있는지 여부였습니다. 우리는 포괄적 인 비즈니스 모델을 개발하는 데 몇 달 동안 집중했지만 여전히 몇 달 동안 시스템 설계를 완료했습니다.

이 수석 개발자는 매우 예리합니다. 가장 긴 동안,그는 아무 말도하지 않았다,생각에 손실. 마지막으로,모든 주위에 벽에 반죽 상세한 비즈니스 다이어그램을 찍고,그는 말했다,”우리는 이미 코딩을 시작했다면,나는 우리가 전혀 기회가 없었 말할 것입니다. 그러나 우리가 아직 코딩을 시작하지 않았기 때문에,나는 기회가 꽤 좋다고 말하고 싶습니다.”

나는 그의 의미를 파악하기 전에 내 마음에 여러 번 실행했다. “우리가 이미 코딩을 시작했다면,나는 우리가 전혀 기회가 없다고 말할 것입니다.”

나는 그가 응용 프로그램 코딩 자체가 꽤 힘들 것이라고 생각 알고 있었다. 규칙 엔진,전 세계 배포 네트워크,그래픽 사용자 인터페이스 및 몇 가지 중요한 미들웨어를 사용하는 것이 포함됩니다.

그는 그들이 코딩하는 동안 모든 비즈니스 문제를 해결해야한다면,그들은 시간에 해내하지 않을 것이라고 말하고 있었다-아마 이제까지. 그러나 프로젝트 팀이 어려운 비즈니스 문제(비즈니스 규칙 지정 포함)를 선행적으로 다루었 기 때문에 목표 날짜까지 코드를 완료 할 수있는 꽤 좋은 기회가 있다고 생각했습니다.

대체로 비즈니스 규칙 접근 방식은 단순히 올바른 사람들에게 올바른 질문을하는 것입니다. 이 정직하게 마감 시간을 충족 할 수있는 유일한 방법은-그리고 먼저 비즈니스 문제를 해결하는 것입니다.

비즈니스 중심 비즈니스 시스템 구축 초기에 비즈니스 측면은 본질적으로 앉아서 그냥 일어날 수 있습니다. 자동화의 이점은 당신이 실제로 아무 잘못도 할 수 없었다 때문에 이렇게 강제적이었다. 이제,모든 실제적인 목적을 위해,사업과는 불가분의 작동합니다. 프로젝트를 수행 할 때 논리적 인 단계는 원활한 비즈니스/프로젝트 팀을 구성하고 요구 사항 개발에 대한 비즈니스 지향 접근 방식을 따르는 것입니다. 그러나 오늘날 많은 기업들이 그 일을 거의하지 않습니다.

모든 너무 자주,비즈니스 측면 여전히 퍼지,병 집중”요구 사항”을 생산 하 고 그것 측”요구 사항”단지 한 단계 또는 두 프로그래밍 위의 일을 계속. 비즈니스 전문가와 요구 사항 개발 전문가 간의 이러한 격차를 어떻게 제거 할 수 있습니까?

대답은 비교적 간단합니다. 비즈니스 요구 사항의 개발을 구동하기 위해 비즈니스 전문가를 가능하게하는 조직 접근 방식이 필요합니다. 이 접근 방식은 적절한 시간에 올바른 일에 대해 올바른 종류의 질문을하는 방법을 보여주는 로드맵을 제공해야합니다. 필요한 것은 비즈니스 중심의 접근 방식입니다.

전통적인 개발 접근 방식에서는 선행 요구 사항을 실제 실행 시스템으로 변환하는 데 많은 부분이 손실됩니다. 그러나 명확한 비즈니스 규칙 집합을 작성하면 비즈니스 측면과 비즈니스 측면 간의 커뮤니케이션이 향상되고 비즈니스 분석과 시스템 설계 간의 브리지가 제공됩니다. 비즈니스 규칙 접근 방식은 비즈니스 측면과 비즈니스 측면 간의 요구 사항 격차를 줄이는 데 도움이됩니다.

그래서 비즈니스 규칙은 무엇입니까? 사업 관점에서,행동을 좌우하나 인도하기 위하여 예정되는 지시 이다. 비즈니스 규칙은 말 그대로 비즈니스 관행에 대한 인코딩 된 지식입니다. 비즈니스 규칙은 재사용 가능한 비즈니스 논리의 원자적인 부분입니다.

어떤 면에서 모든 사람들은 비즈니스 규칙이 무엇인지 알고 있습니다. 비즈니스 규칙이 없으면 항상 사례별로 대안을 선택하여 즉시 결정을 내려야 합니다. 그런 식으로 일을하는 것은 매우 느릴 것입니다.

규칙은 실생활에서 우리 모두에게 친숙합니다. 우리는 규칙에 의해 게임을,우리는 규칙의 집합에 따라 법률 시스템 아래 살고,우리는 우리의 아이들을위한 규칙을 설정. 그러나 사업 체계안에 규칙의 아이디어는 최대량에게 반어로 외국 그것 전문가 이다. “규칙”을 말하고 많은 전문가들은 전문가 시스템이나 인공 지능을 모호하게 생각합니다. 비즈니스의 기본적이고 일상적인 운영에 핵심적인 규칙이 실제로 어떻게 적용되는지에 대한 인식은 거의 없습니다.

우연히도 많은 비즈니스 측 근로자와 관리자는 규칙 측면에서 생각하는 것이 외국적이거나 추상적 인 것처럼 보일 수있는 요구 사항을 개발하기 위해 절차 적 견해에 너무 잘 주입되었습니다. 사실상 모든 방법론은 비즈니스 프로세스 재 엔지니어링,시스템 개발 또는 소프트웨어 설계 여부에 관계없이 이와 관련하여 유죄입니다.

이것은 두 가지 이유로 불행합니다:

1. 규칙의 관점에서 조직 된 활동에 대해 생각하는 것은 실제로 매우 자연 스럽습니다. 예를 들어,규칙을 설명하지 않고 체스,체커,야구 또는 축구와 같은 게임을 설명하려고한다고 상상해보십시오.

2. 비즈니스 측 노동자와 관리자는 좋은 규칙을 만드는 데 걸리는 지식을 가지고있다.

샘플 규칙

따르는 샘플 규칙을 살펴보고 비즈니스 시스템에서 운영 통제의 모든 측면을 규칙으로 해결할 수 있는지 확인합니다.

•휴리스틱: 선호하는 상태의 고객은 주문을 즉시 채워야합니다.

•계산:고객의 연간 주문량은 회사의 회계 연도에 마감된 총 판매량으로 계산해야 합니다.

•추론:고객이$1,000 이상 5 개 이상의 주문을 하는 경우 고객이 선호되는 것으로 간주되어야 합니다.

•타이밍:고객이 36 개월 연속 주문을하지 않으면 고객을 보관해야합니다.

•트리거:주문이 배송 될 때 주문에 대해”사전 통지 보내기”를 실행해야합니다.

규칙은 용어와 사실에 직접 구축. 고객,선적 및 송장과 같은 용어는 비즈니스에서 정확하고 명확한 정의를 가져야합니다. 예를 들어,고객은 다음과 같이 정의 될 수 있습니다:”이전 2 년 동안 하나 이상의 유료 주문을 한 조직 또는 개인.”

사실은”고객이 주문합니다.”

“팩트 모델”은 비즈니스 운영의 결과를 설명하는 팩트 문 집합입니다. 팩트 모델은 데이터 모델의 초기 청사진으로 사용되어야 하지만,그 주된 목적은 비즈니스에 대한 지식을 구조화된 형태로 캡처하고,이를 소유한 비즈니스 측 직원 및 관리자로부터 증류 하는 것입니다.

규칙은 기본적으로 단어의 의미를 추가해야하거나하지 말아야 조건과 사실,에서와 같이,”$1,000 이상 신용에 주문은 신용 확인없이 받아 들여서는 안됩니다.”

규칙은 명확한 주제로 시작하여 명확하고 명확하며 잘 구조화 된 비즈니스 영어로 표현되어야합니다. 규칙은 더 보풀없이 누락 된 사실이 없어야합니다. “선적 값이$500 보다 큰 경우 선적 보험에 가입해야합니다.”그리고 규칙은 타이밍 기준을 포함 할 수 있습니다,에서와 같이”학생은 등록의 마지막에 의해 적어도 두 개의 과정에 등록해야합니다.”

규칙 독립

사업은 인체와 매우 흡사하다. 지식(용어 및 사실)구조는 골격 처럼;프로세스는 강력한 근육;그리고 규칙은 다른 두를 제어 하는 신 경계. 세 가지 모두 필수적이며 상호 연관되어 있습니다. 그러나 비즈니스 규칙은 다른 두 규칙과 분리되어야합니다. 이 접근법의 기본 원칙은 규칙이 프로세스 및 절차와 독립적이라는 것입니다. 그”규칙 독립성”의 부가적인 이점은 프로세스에서 거대한 단순화입니다.

결과는”씬 프로세스,”많은 전문가들의 오랜 목표입니다. 프로세스에서 규칙을 복용 하 여 비교적 간단 하 고 필요에 따라 변경할 수 있습니다 프로세스를 생성할 수 있습니다.

내셔널 풋볼 리그에서,연극이 팀을 위해 작동하지 않는 경우,그것은 게임의 몇 내에서 플레이 북에서 사라질 것입니다. 연극은 본질적으로 도주입니다. 마찬가지로,기업은 폐기하고 절차가 더 이상 잘 작동하지 않을 때 쉽게 교체 할 수있을만큼 저렴—도주 자신의 절차를 볼 필요가있다.

일회용 절차는 기업이 적응력과 경쟁력을 갖추기 위한 필수 요소입니다. 이 믿을 수 없을 정도로 간단한 아이디어—비즈니스 규칙 접근 방식에 의해 가능-작업 수행 및 시스템 설계 방식에 혁명을 일으킬 수 있습니다.

로널드 지 로스(애디슨-웨슬리,2003)에 의해 비즈니스 규칙 접근법의 원칙으로부터 허락을 받아 재판. 로스는 공동 설립자 및 비즈니스 규칙 솔루션 유한회사의 교장 및 웹 사이트의 편집장입니다 BRCommunity.com.

라이브러리 팩트 모델
이 다이어그램은 라이브러리에 대한 그래픽 팩트 모델을 보여줍니다. 이 규칙의 표현은 기본 비즈니스 개념(지식 구조)의 다이어그램 인 사실 모델을 직접 기반으로합니다. 팩트 모델은 데이터가 결국 데이터베이스에서 어떻게 구성되는지에 대한 첫 번째 컷 블루프린트를 제공할 수 있고 제공해야 합니다. 규칙: 도서관 카드는 책이 카드가 승인 된 도서관이 소유 한 경우에만 책을 체크 아웃하는 데 사용할 수 있습니다.