견적에서 입금까지

많은 중소기업에서 하나의 프로젝트가 여러 소프트웨어에 흩어져 있습니다.

영업은 Quotation을 작업하고 있습니다.

프로젝트 매니저는 Project를 관리하고 있습니다.

구매팀은 Suppliers를 찾고 있습니다.

회계팀은 Expenses를 기록하고 있습니다.

그리고 마지막으로 재무팀이 Invoice를 보내고 대금을 독촉합니다.

모두가 같은 고객 프로젝트의 일부만을 보고 있습니다.

하지만 사장이 진짜로 궁금한 것은 전체 이야기입니다:

얼마에 견적했는가?

실제로 얼마가 들었는가?

약속한 것을 납품했는가?

얼마를 청구했는가?

최종적으로 얼마의 현금을 회수했는가?

그래서 Snappy PM을 설계할 때, 이것들을 처음부터 연결하고 싶었습니다.

프로젝트는 고객의 요구사항에서 시작합니다.

Requirements는 점차 Scope가 됩니다.

Scope는 결국 Quotation이 됩니다.

고객이 Quotation을 수락한 후에야 우리는 비로소 진짜를 알게 됩니다:

무엇을, 얼마에 납품하기로 약속했는가?

그러고 나면 프로젝트는 Implementation이나 Manufacturing으로 들어갑니다.

자재, 구매, 인건비 및 기타 Expenses가 발생하기 시작합니다.

이것들은 더 이상 재무 시스템에 흩어져 있는 비용이 아닙니다.

이 Project에 속하는 것들입니다.

그래서 우리는 점차 볼 수 있게 됩니다:

Quoted Revenue

Cost to Date

Work in Progress

Expected Margin

그리고 Delivery가 일어납니다.

마지막으로 Closing에 들어갑니다:

Invoice → Payment → Settlement → Close.

이 시점에서 Accounting과 Project Management는 더 이상 완전히 다른 두 세계가 아니어야 합니다.

사장에게는 원래부터 같은 하나의 일이었으니까요.

200,000 AED짜리 프로젝트가 결국 130,000 AED가 들었습니다.

이 130,000은 왜 예산보다 높았을까요?

자재 때문이었을까요?

인건비?

Scope Change?

Installation?

이 질문들에 대한 답은 몇 달 후에 회계사가 P&L을 내놓을 때까지 기다릴 필요가 없습니다.

프로젝트가 진행되는 동안 점차 보이게 되어야 합니다.

이것이 Snappy PM을 설계할 때 매우 중요한 방향이기도 합니다:

Project Management는 결국 Accounting의 숫자를 설명할 수 있어야 합니다.

그리고 Accounting은 반대로 Project Manager에게 말해줘야 합니다:

프로젝트에서 실제로 무슨 일이 일어났는지.

Quotation은 고립된 PDF가 아닙니다.

Purchase는 고립된 Expense가 아닙니다.

Invoice도 프로젝트가 끝난 뒤 갑자기 나타나는 청구서가 아닙니다.

모두 같은 상업 프로세스가 남긴 서로 다른 기록들입니다.

이 기록들을 연결해야만 사장이 진짜로 궁금해하는 질문에 답할 수 있습니다:

이 프로젝트에서 정말 돈을 벌었는가?

그리고 더 중요한 것은:

왜?

SnapLedger, your life easier.