คนมักเริ่มมองหาผู้พัฒนาแอปพลิเคชันธุรกิจเฉพาะทาง เมื่อซอฟต์แวร์ในตลาดแต่ละตัวตอบโจทย์ได้คนละส่วน แต่ไม่มีตัวไหนเดินตามลำดับงานจริงได้ครบ สุดท้ายช่องว่างเหล่านั้นก็ถูกอุดด้วยสเปรดชีต การกรอกข้อมูลซ้ำ และความเคยชินภายในองค์กร
ก่อนจะขอใบเสนอราคา ควรตัดสินใจบางเรื่องภายในองค์กรให้เรียบร้อยก่อน เพราะการตัดสินใจเหล่านั้นส่งผลโดยตรงต่อขอบเขตงาน และจึงส่งผลต่องบประมาณ
อะไรนับเป็นแอปพลิเคชันธุรกิจ
แอปพลิเคชันธุรกิจไม่ได้เป็นเพียงเว็บไซต์หรือแดชบอร์ด แต่คือซอฟต์แวร์ที่งานส่วนหนึ่งขององค์กรเกิดขึ้นข้างในจริง ๆ มีข้อมูลที่แทนสิ่งที่มีอยู่จริง มีสถานะที่ข้อมูลนั้นเคลื่อนผ่าน มีสิทธิ์การใช้งานต่างกันตามบทบาท มีประวัติว่าใครแก้อะไร และมีการแลกเปลี่ยนข้อมูลกับระบบอื่นในองค์กร
นี่เป็นเหตุผลที่โปรเจกต์แบบนี้ต้องตัดสินกันในระยะยาว เว็บไซต์ทำใหม่ได้ แต่แอปพลิเคชันธุรกิจถูกใช้งานทุกวัน และข้อบกพร่องของมันถูกจ่ายเป็นนาทีที่เสียไปในการใช้งานแต่ละครั้ง
ทำเองหรือซื้อสำเร็จรูป
การทดสอบที่มีประโยชน์ที่สุดไม่ใช่การเทียบรายการฟีเจอร์ แต่คือลำดับการทำงาน ถ้าซอฟต์แวร์หลายตัวครอบคลุมกระบวนการคนละส่วนแต่ไม่จัดการรอยต่อระหว่างกันให้ดี คุณอาจต้องจ่ายทั้งค่าสมาชิก ทั้งเสียเวลากรอกข้อมูลซ้ำ และทั้งหาทางเลี่ยงด้วยมือไปพร้อมกัน ต้นทุนรวมนี้ต่างหากที่ควรนำไปเทียบกับการทำเอง ไม่ใช่แค่ราคาไลเซนส์
การทำเองคุ้มค่าที่สุดเมื่อบางส่วนของวิธีทำงานของคุณเป็นข้อได้เปรียบในตัวมันเอง เช่น วิธีคัดกรองลูกค้า กติกาการตั้งราคา หรือการตรวจคุณภาพที่ทำให้คุณต่างจากคู่แข่ง ส่วนการจ้างพัฒนาเฉพาะทางเพื่อตอบโจทย์ที่ซอฟต์แวร์ในตลาดครอบคลุมดีอยู่แล้ว มักไม่คุ้มทุน
งบประมาณหมดไปกับอะไร
- การวางขอบเขต คือการเข้าใจกระบวนการจริงรวมถึงกรณียกเว้น มักเป็นรายการแรกที่คนอยากตัดงบ แต่สิ่งที่ไม่ถูกทำความเข้าใจในขั้นนี้ มักย้อนกลับมาทีหลังในรูปของการแก้งาน กติกาที่ลืมไป หรือขอบเขตที่เปลี่ยน
- โครงสร้างข้อมูล ว่าหนึ่งรายการคืออะไร มีสถานะใดบ้าง และอะไรที่ต้องเป็นจริงตลอดเวลา การตัดสินใจผิดตรงนี้จะลามไปทั้งระบบ และแก้ได้ยากขึ้นมากเมื่อข้อมูลและกติกาทางธุรกิจถูกสร้างทับไปแล้ว
- การเชื่อมต่อระบบ แต่ละระบบที่ต้องเชื่อมอาจกลายเป็นงานก้อนหนึ่งในตัวเอง ต้องเข้าใจสิทธิ์เข้าใช้ ข้อมูลที่มันเปิดให้ ข้อจำกัดของมัน และสิ่งที่เกิดขึ้นเมื่อการรับส่งข้อมูลล้มเหลว
- การย้ายข้อมูลเดิม ควรคิดต้นทุนแยกต่างหาก โดยเฉพาะเมื่อข้อมูลย้อนหลังถูกกรอกด้วยมือมาหลายปี และมีทั้งรายการซ้ำและรูปแบบที่ไม่สอดคล้องกัน
- การอบรมใช้งานและเอกสารประกอบ ถ้าขาดสองอย่างนี้ เครื่องมือจะกลายเป็นสิ่งที่มีคนเดียวใช้เป็น
- การดูแลรักษา ที่ต้องวางงบไว้ตั้งแต่ต้น เพราะ API เปลี่ยนไปเรื่อย ๆ รหัสเข้าใช้งานหมดอายุหรือถูกเปลี่ยน และความต้องการทางธุรกิจก็ขยับตลอด
ห้าเรื่องที่ต้องตัดสินใจก่อนไปคุย
- ใครเป็นผู้ใช้แอปพลิเคชัน และมีสิทธิ์ระดับไหน การกำหนดบทบาทและสิทธิ์ให้ชัดตั้งแต่ต้น ออกแบบได้ถูกกว่าการพูดลอย ๆ ว่าผู้ใช้งาน แล้วค่อยมาชัดเจนระหว่างพัฒนา
- ข้อมูลถูกเก็บไว้ที่ไหน และข้อมูลส่วนไหนเป็นข้อมูลส่วนบุคคล ควรตัดสินก่อนออกแบบ ไม่ใช่หลังจากนั้น
- ใครเป็นเจ้าของโค้ด และที่เก็บโค้ดกับสิทธิ์เข้าถึงระบบจริงอยู่ภายใต้บัญชีของใคร
- ต้องย้ายข้อมูลย้อนหลังมาทั้งหมดจริงหรือไม่ การย้ายข้อมูลหลายปีมีต้นทุนไม่เท่ากับการย้ายเฉพาะส่วนที่ทีมยังใช้งานอยู่ทุกวัน
- กำหนดให้ชัดว่าอะไรต้องใช้งานได้ก่อน การส่งมอบส่วนแรกที่ใช้งานได้จริงบนระบบจริง ช่วยให้ยืนยันการตัดสินใจได้ก่อนจะขยายขอบเขตต่อ
งานที่เราเคยสร้าง
ทุกวันนี้การพัฒนาแอปพลิเคชันธุรกิจเฉพาะทางคือหัวใจของงานเรา สำหรับ Mutualys ซึ่งเป็นบริษัทแม่ของ Normandie Santé งานจบลงที่ CRM ที่พัฒนาขึ้นเองและแชตบอต WhatsApp เพราะการดูแลลูกค้ามุ่งหวังกระจายอยู่ระหว่างอีเมล บันทึกการโทร และสเปรดชีต
สำหรับ Orange VOD เราส่งมอบแคมเปญอินเทอร์แอ็กทีฟสิบเอ็ดชุดระหว่างปี 2012 ถึง 2016 บนฐานร่วมเดียวกัน แทนที่จะเริ่มใหม่ทุกครั้งที่มีหนังออก ซึ่งทำให้กรอบเวลาส่งมอบสองสัปดาห์เป็นไปได้จริง เทคโนโลยียุคนั้นเก่าไปแล้ว แต่หลักคิดยังใช้ได้ นั่นคือการเปลี่ยนกระบวนการที่ทำซ้ำ ให้กลายเป็นแอปพลิเคชันที่ตั้งค่าได้
