行動數位時代與商業發展趨勢

行動數位時代
與商業發展趨勢
鍾明旭PMP / ACP
103.11.8
jongminshi@gmail.com
版權所有，引用時請註明出處1

行動數位時代與APP商業發展
數位時代
行動化數位時代
APP商業應用
商業分析與敏捷式專案管理
M
BA
A
APP製作、資料庫與大數據
D
SQL

數位時代
• 類比(電視)  數位化(PC/手機/平板)
• PC  手機/平板

行動化數位時代
• 近年來智慧型手機用戶直線上升，手機業
者為搶得先機皆不斷的推出創新產品，以
佔有更大的市場。
• 因此3G手機已成為我國行動通訊系統之主
流。隨著時代變遷及科技發展，通訊與資
訊產品漸漸普遍，行動電話已是現代人不
可或缺的一項通訊工具。而隨著行動通訊
發展至多功能智慧型手機，使得人們隨時
可透過手機存取資料、瀏覽資訊網路，資
訊的取得與分享也變得更為快速。

APP商業應用
• 智慧型手機(SmartPhone)有別於一般的手
機，除了傳統打電話、照相、錄影功能、
MP3及影音播放功能外，因可隨意於手機
內安裝應用軟體功能，所以吸引越來越多
的軟硬體廠商相繼投入智慧型手機產業，
技術上也不斷地突破與改進，提高了智慧
型手機之產品穩定度、成熟度與可用性，
亦大幅地提升智慧型手機的易用性，讓智
慧型手機的普及率年年增高，順應硬體利
潤逐漸下滑，主流業者紛紛朝軟體服務的
發展前進。

行動應用程式
•隨著智慧型手機和平板電腦等行動裝置的快速普
及，帶動行動應用程式(Mobile Application，簡稱
App)的不斷開發
•除了有趣的小遊戲之外，也能提供許多生活相關
資訊。
•App目前在電子商務的應用大致分成三類：
–(1)透過有趣的應用，以增強品牌的形象與知名度；
–(2)將App與社群網站的分享機制結合，達到口碑行銷；
–(3)直接讓消費者隨時完成消費行為

App開發技術主要分類
•原生應用程式(Native App)開發
•網頁應用程式(Web App)開發
•混合式應用程式(Hybrid App)開發

(1) 原生應用程式(Native App)開發
• 由手機或平板作業系統廠商，自行提供SDK或建議的開發
方式，例如
– iOS App：使用Xcode與Objective-C開發，上架到App Store上
–Android App：使用Eclipse與Java開發，上架到Google Play，或直接
執行apk安裝檔
–Windows Store App：使用Visual Studio與C/ C++/ C#/ VB.NET/
HTML5與Java Script開發，上架到Windows Store
• 優點
– 善用手機的特性(例如GPS定位、相機攝影鏡頭、感應器等)、更好
的執行速度和使用者體驗、支持離線運作、提供較豐富的圖形和
動畫、在應用商店輕易地找到應用及安裝；
• 缺點
– 開發成本較高、上架時間(應用商店審查程序)較長、使用者須手動
下載更新版本、下載應用可能需要付費。

(2) 網頁應用程式(Web App)開發
•使用HTML5、CSS及Java Script等網頁技術開發的
應用程式
–可同時於桌上型或行動設備的瀏覽器中執行
•優點
–支援不同作業系統與平台的行動設備、開發成本較低
、方便快速地部署(無需提交到應用商店)、使用者無須
更新即可使用最新版本
•缺點
–需透過網路連線導致速度較慢、無法充分運用手機的
特性、開發者較難藉由使用者下載應用而獲利

(3) 混合式應用程式(Hybrid App)開發
•以網頁應用程式開發客戶端程式
•再透過PhoneGap等框架工具跟行動裝置互動
•最後包裝上原生應用程式的外殼，上架至應用程式
商店。
•優點
–較原生應用程式支援較多的平台、適用於應用程式商店、
部分支援離線功能；
•缺點
–仍須上架時間、速度及使用者體驗不如原生應用程式、
相關技術尚未成熟、無法完全支援各種行動裝置。

敏捷宣言
個人與互動重於流程與工具
可用的軟體重於詳盡的文件
與客戶合作重於合約協商
回應變化重於遵循計劃

敏捷12原則
1. 我們最優先的任務，是透過及早並持績地交付有價值的軟體，來滿
足客戶需求。
2. 竭誠歡迎改變需求，甚至已處開發後期亦然。敏捷流程掌控變更，
以維護客戶的競爭優勢。
3. 經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔
為佳。
4. 業務人員與開發者，必須在專案全程中天天一起工作。
5. 以積極的個人來建構專案，給予他們所需的環境與支援，並信任他
們可以完成工作。
6. 面對面的溝通，是傳遞資訊給開發團隊及團隊成員之間，效率最高
且效果最佳的方法。

敏捷12原則
7. 可用的軟體是最主要的進度量測方法。
8. 敏捷程序提倡可持續的開發。贊助者、開發者及使用者
應當能不斷地維持穩定的步調。
9. 持續追求優越的技術與優良的設計，以強化敏捷性。
10.精簡──或最大化未完成工作量之技藝──是不可或缺的。
11.最佳的架構、需求與設計皆來自於能自我組織的團隊。
12.團隊定期自省如何更有效率，並據之適當地調整與修正
自己的行為。

敏捷方法論
-Scrum
-XP (eXtreme Programming)
-Kanban
….

Projects and the SDLC
Product Scope
Requirements
Design
Test
Release
Plan
Monitor &
Control
Implement
Close
Build
PMI Project
Management Process Waterfall Development
Initiate

IIBA Business Analysis
and the BABOK
https://www.youtube.com/watch?v=We1VW8MDn_k&list=PLjF-BzEQNIVNMO3RM1zjPwCkNiNduKABv

Plan Do Check Act
Test
Release
Close
Build
Etc.
PMI Project
SIX Sigma
Rational
Etc.
Management Process Waterfall Development

Project Failures
There are many reasons why projects fail.
Poor strategic
alignment
Lack of handover
(people change management)
Long time to
delivery
Poor or wrong
requirements
Poor risk
management
Poor
planning
Lack of sponsor
involvement
Ineffective
communication
Poorly defined
objectives/scope
Team skills
(esp. interpersonal skills)
Lack of formal pm
processes
Poor requirements management is consistently
in the top 3 reasons, regardless of the source

The cost of bad requirements
The following are a few key findings and data from the study:
1. Companies with poor business analysis capability will have three
times as many project failures as successes.
2. 68% of companies are more likely to have a marginal project or outright
failure than a success due to the way they approach business
analysis. In fact, 50% of this group’s projects were “runaways” which had
any 2 of:
• Taking over 180% of target time to deliver.
• Consuming in excess of 160% of estimated budget.
• Delivering under 70% of the target required functionality.
3. Companies pay a premium of as much as 60% on time and budget when
they use poor requirements practices on their projects.
4. Over 41% of the IT development budget for software, staff and external
professional services will be consumed by poor requirements at the
average company using average analysts versus the optimal organization.
5. The vast majority of projects surveyed did not utilize sufficient
business analysis skill to consistently bring projects in on time and
budget. The level of competency required is higher than that employed
within projects for 70% of the companies surveyed.

Swim lanes
Actor 4 Actor 3 Actor 2 Actor 1
Verb/noun
Binary
decisions
Activity level
participants
Boundaries
Hand-over
Begin and end
in same lane

Context diagrams
Information
flow
External
Internal
Drilling
down
Context
Boundary

專案管理應用
PMIS專案管理資訊系統

必樂思(bizalyst)PMIS
範例介紹-經濟部XX局
計畫管理作業平台
Copyright © 必樂思bizalyst.com.tw All rights reserved 28

一、硬體環境架構
設備規格：
CPU：Intel Xeon E5420 2.5GHz
RAM：8 GB
HD：500 GB
作業系統：Windows Server 2008 Service Pack 2
資料庫：Microsoft SQL Server 2012
AP Server：Apache-tomcat-7.0.39
二、軟體架構
Copyright © 必樂思bizalyst.com.tw All rights reserved

三、設計原則與規範
預計P
簽約版計畫書內容數位化，著重於時
間(進度追蹤)與查核點(check-point)完成情況
原則：
規範：
1/ 單一計畫單一帳號密碼簽入功能
2/ PO僅扮演輔佐長官管考計畫執行內容角色
3/ 嚴格「權限功能」設計與執行
4/ 履約內容變化登錄，詳實紀載「歷程」
5/ 強化「彙整報表」輸出成Word or Excel文件功能
6/ 系統管理者權限僅限「系統功能」，不擴及「計畫管考資料」更改暨修訂
實際C
執行D與計
畫變更A

103年度系統功能擴充與升級架構圖

103年度系統功能擴充與升級架構圖
功能模組
計畫執行單位計畫管理辦公室承辦人、科長、組長
P 專案管理_ 計畫書設定專案管理_ 計畫書管理(預審) 專案管理_ 計畫書管理(審核)
D
進度回報_ 績效推廣規劃
進度回報_ 查核點回報
進度回報_ 月成果回報
進度回報_ 履約報告上傳
進度回報_ 履約成果回報
出國計畫_ 出國申請
出國計畫_ 回國回報
C
計畫變更_ 變更公文管理計畫變更_ 計畫變更管理計畫變更_ 計畫變更管理
計畫變更_ 人力變更進度回報_ 規劃暨回報查詢進度回報_ 規劃暨回報查詢
計畫變更_ 經費變更
(含工作項目暨查核點變更)
進度回報_ 查核點回報管理
專案控管_ 顧問名單查詢專案控管_ 顧問名單查詢
專案控管_ 委員資料查詢專案控管_ 委員資料查詢
專案控管_ 人月勾稽查詢
進度回報_ 履約報告管理進度回報_ 履約報告管理
進度回報_ 履約成果管理進度回報_ 履約成果管理
出國計畫_ 出國申請管理
出國計畫_ 回國回報管理
A 進度回報_ 查核點回報管理註
出國計畫_ 出國申請管理
註：於進度回報_ 查核點回報管理功能內，設計有承辦人退回功能，即承辦人可以將查核點由計畫
執行單位填報之「已完成」更改為「未完成」。

專案管理_ 計畫書管理(審核)
功能說明：紙本簽約版計畫書重要內容之電子化。
用途：登載計畫重點內容，如基本資料、履約期程(期中/期末繳交日期)、人力、經
費、查核點預計完成日期等。
PO工作：協助承辦人做計畫執行單位膳打系統資料之核對。
承辦人工作：經double-check後審查通過，即簽約版計畫書電子資料凍結。

計畫變更_ 計畫變更管理
功能說明：用於事後報備經能源局
審查後之人力/經費/工作項目暨查
核點變更項目內容。
用途：局內長官可看到業管計畫之
計畫變更內容。
PO工作：
1.協助承辦人查詢跨計畫人力登錄
總計，是否超過12人月。
2.確認能源局核備公文內容，是否
與系統登載相符。
承辦人工作：無。

進度回報_ 查核點回報管理
功能說明：查詢計畫重要履約要項(查核點)之完成情形。
用途：用以追蹤計畫查核點之完成情形，並可產出報表，以了解查核點履約歷程與
最後完成入期。
PO工作：於查核點預計完成日期前7天，提醒計畫執行單位上網提報履約狀態。
承辦人工作：可double-check計畫查核點之完成情形，若不認可填報資料與實際
完成日期時，可進行退回動作。

進度回報_ 規劃暨回報查詢
功能說明：查詢計畫每月份廣宣活動之規劃與實際執行內容回報。
用途：查詢計畫每月份廣宣活動之規劃與時寄回報內容，並產生報表供會議討論。
PO工作：提醒與稽催計畫填報資料。
承辦人工作：無。

出國計畫_ 出國狀態查詢
功能說明：查詢所屬計畫出國狀態。
用途：查詢所屬計畫出國狀態，並區分為執行單位申請中、準備中、出國中、已回
國。
PO工作：無。
承辦人工作：承辦人對業管計畫出國申請作內容審核後，即可使組長、科長查詢。

未完成(主要)工作說明：
1.儀表板功能模組建置
2.計畫工作項目、查核點儀表板功能，以一頁(one-page)「長條圖」方式展現
「預計vs實際」執行情形

成果管理與期末盤點
履約過程中，即時彙整
並確認PMIS資料正確性
（如期、如質、如預算
執行）
能源前瞻關鍵議題研究
(五大領域)，並完成機關
年度施政計畫(報上級機關任
務)規劃與提報
建立能源局Top-Down
核心任務(如節能、綠能
推動..)與各業務組任務
展開至計畫執行之連結
建立核心任務與計畫執
行成果之連結性（即建
立成果Bottom-Up至核
心任務KPI）並編列預算
當年度計畫履約執行、
回報與管考作業
計畫成果效益與
核心任務連結確認
成果效益與核心任務
達成之檢討與改進
滾動式精進與修正
各計畫任務與做法
不可能且未完成(主要)工作說明（紅色部分為未完成部分）

•第一章快速介紹現況。
•第二到四章談方法學的典範轉移：
從研究樣本到研究母體，從執著資料品質
到擁抱不確定性，從追求因果關係到充分
利用相關性。
•第五到七章談的是研究過程，著重
巨量資料的基礎建設、運用方式與
價值鏈。
•第八到十章則分別談風險、管控與
未來。

Big Data三種層次：巨量、即時性
和多樣性。
三種大數據時代的新思維。
•第一種新思維是「樣本＝母體」
•第二種新思維是「擁抱不精確」
•第三種新思維是「找到相關性，不
再追求因果關係」

如何從巨量雜訊中，看出重要的訊
息？
•機率思考- 「角色」與「立場」
Q ：產品到底有沒有市場性？
•如實搜集各種情報與調查
=「樣本外」的重大新資訊
•不預設立場，勇於隨時因情勢變化

雲端運算(主)架構：Hadoop
https://www.youtube.com/watch?v=9s-vSeWej1U
Apache Hadoop簡介
http://readwrite.com/…/23/hadoop-what-it-is-and-how-it-works
Apache Hadoop迷思(From科技報橘)
http://buzzorange.com/techorange/2013/06/04/7-myths-on-big-data-
avoiding-bad-hadoop-and-cloud-analytics-decisions

雲端運算兩大架構：Hadoop & Scala
https://www.youtube.com/watch?v=9s-vSeWej1U
Hadoop簡介
http://readwrite.com/…/23/hadoop-what-it-is-and-how-it-works

附錄一：
商業分析CBAP認證介紹

壹、商業分析師介紹
商業分析術語：
1.BA目的：在於引出需求，開發商機，而非企業評價
2. 程序：problem (pain/need)  requirements 
solution (wants)
3. Task = 必要工作，即BA基本功
4. Solution = deliverables of project/program
Copyright © 財團法人中衛發展中心All rights reserved

貳、BABOK架構與概論
• BABOK=Business Analysis Body of
Knowledge

1. Introduction to the BABOK (商業分析知識體系介紹)
2. Business Analysis Planning &Monitoring (商業分析計畫
與監控)
3. Elicitation (需求引出)
4. Requirements Management & Communication (需求管
理與溝通)
5. Enterprise Analysis (企業分析)
6. Requirements Analysis (需求分析)
7. Solution Assessment and Validation (解決方案的評估與
確認)
参、BABOK內容概論

2.Planning & Monitoring

3.Elicitation

4.Requirements Management &
Communication

5.Enterprise Analysis

6.Requirements Analysis

7.Solution Assessment &
Validation

8./9.Underlying Competencies
8.1 8.2 8.3 8.4 8.5 8.6

肆、重要觀念1
•馬斯洛「需求層次理論,
hierarchy of needs」：先滿足生
理需求，再求心理需求
•各Stakeholder需求皆不同（一
樣的米養百樣的人）
=赫茲伯格
「雙因素理論」
中的「保健因
素」

肆、重要觀念2
•需求在專案執行過程中，需區分需求狀態，以利追
蹤(過程確認)
•Verify vs Validate
•“Do the thing right” vs “Do the right thing”

肆、重要觀念3
•需求分四部份，依組織層級而有區分
Business
Requirement
Stakeholder
Requirement
Solution Requirement
Transition
Requirement
Business
Requirement
Stakeholder
Requirement
Solution Requirement
配套錯施
不同位階
&視野
5. EA
不同立場
6.RA
不同目的
不同時間

技巧
•溝通
肆、重要觀念4

•BA vs PM
肆、重要觀念5

附錄二：新產品開發知識領域

企業使命、願景、價值
使命:
一個公司的信念、哲學、目標、商業原則或企業信仰的正式
聲明，目的
是要凝聚組織的能量與資源。
願景:
一種先見之明與識別的想像活動，揭露了可能性與實務上的
限制，他描
述了組織最渴望的未來
價值:
所有參與完成使命的成員須遵循的行為準則75

新產品開發六大知識領域
開發策略
開發流程
組合管理
市場研究
工具評量
團隊組織
15%
20% 20%
20%
15%
10%

策略概述
策略是一種計劃或方案，管理公司的資源與優勢，以突襲並
超越競爭
者，或開拓新的機會
• 商業策略: 係指公司有關產業定位，商機與資源的計畫，
以便完成公司的長期目標，並根據不同類型的計畫分配投
入的資金
• 平台策略: 是一個核心發展計畫，專為生命週期常與一連
串後續產品而設計的計畫，並強調結構與構造有共通性。
通常平台是相關技術在產品與產品線的最小分母

四個重要的問題
• 誰是主要客群-目標客戶與市場範圍
• 提供什麼產品-決定產品線的深度與廣度
•產品如何與客戶接觸-推廣的渠道
• 客戶為什麼喜歡我們的產品勝過競爭者-客戶找尋的需求
屬性與價值
了解市場
繪製市場
組合圖
評估現有
生產線
了解產品
線圖
繪製產品
線圖
辨識產品
生命週期
建立獲利
模式
找出產業
價值鏈
新產品與
品牌

策略種類
Miles and Snow’s Types
• 探勘者-創新者，第一個進入市場並使用新技術Ex. Honda
• 分析者-快速跟隨者，通常以提供更好的產品進入Ex.
Toyota
• 防禦者-在相對穩定的產品或市場保持穩定與利基Ex.
Nissan
• 反應者-只在被迫時做出反應Ex. Subaru

策略種類(續)
Cooper’s Type
• 區隔型-技術上高度發展，策略符合並集中，強烈市場導向
(差異化策略15.6%)
• 低預算保守型-低研發，模仿，沒區別的產品
(低預算保守策略23.8%)
• 技術推手型-技術高度發展，但市場導向、策略符合與集中協同性低
(科技導向策略26.2%)
• 不在遊戲中型-低技術，低風險，簡單成熟的技術
(局外人策略15.6%)
• 高預算多種類型-研發多，無方向，來亂的人
(高預算多樣化策略18.8%)

市場研究
•初級市場研究: 一種依據公司需求設計的研究方式，以確
實的方法得到目標市場的資訊，通常以統計方法為基礎
Ex. 焦點團體、客戶拜訪、調查、觀察法
• 次級市場研究: 在一個目標下由一個團體所收集的資料，
並由另一個團體使用或提供服務給另一個團體
Ex. 商業報告、銷售資料、客戶資料、會談紀錄、過去市
場研究資料
先研究次級市場資料，再決定是否要做初級市場研究，並應
有階段性

客戶訪問
• 非計畫性的客戶拜訪: 市場研究只是其中目的之一Ex. 參展、業務拜訪
、售後服務
• 計畫性的客戶拜訪: 新產品與新市場開發最常使用
• 客戶訪問的優點: 走出自己的世界、面對面溝通客戶的需求..
• 客戶訪問的缺點: 面訪者的偏差、小樣本的不穩定性與不準確性..
準備客戶訪問時:
• 建立客戶拜訪團隊: 跨部門團隊(訪問者PM/紀錄者Sales/觀察者RD)
• 選擇拜訪客戶: 當地、友善、方便聯繫
• 排定拜訪時程: 每個客戶拜訪以1.5小時~2小時來安排，一天之內不要
超過三個拜訪行程
• 準備拜訪方針: 腦力激盪、問題分類、排定順序
82

組合管理
企業在新產品投資組合管理三大目標:
• 價值極大化-> 長期獲利力、投資報酬率、
產品成功率..
• 平衡性-> 全新產品、產品改良、降低成本
、基礎研究..
• 策略方向-> 經費、市場、區域..
83
政策性
方案
其他
新產品
開發
產品線延伸
降低成本

風險-報酬泡泡圖
84
泡泡圖形式X軸Y軸企業使用比例
風險與報酬回收報酬方案成功率44.4%
新穎度科技新穎度市場新穎度11.1%
難度與吸引力科技可行性市場吸引力11.1%
Auto
Seal
Top
Floor
Grade A
Sealant
U.V. Seal
D-50
Bread and Butter
$10 M 8 6 4 2 0
First
Coat
T-400
SPL
Edge
Coat
Solvent 1
White Elephants
TP-40
Pearls
Deck
Coat
Top
Seal
Solvent
800
Top
Coat A
Oysters
Circle size = resources (annual)
Reward (NPV)
High
Low

團隊組織
新產品開發專案團隊的成立
• 什麼時候該建立跨部門團隊?
• 徵招相關技能與經驗人才
• 召開Kick-off會議，讓團隊成員清楚了解
• 專案計畫
• 團隊合作與獨立工作
• 部門支援
衝突管理
• 工作分解結構WBS (Work breakdown structure)
•責任指派矩陣RAM (Responsibility Assignment Matrix)
85

專案的五大要素
負責人
Who
任務
How
成本
How
much
目標
Why
What
時間線
When
86
計畫vs.表現預算vs.花費

責任矩陣與當責
問卷調查責任矩陣R:負責S:支援
工作項目阿勇小李大支秀秀
設計問卷內容A R C
設定問卷對象A C R
87
印製問卷C A I R
執行問卷調查C A I R
輸入問卷資料C A R
分析問卷結果A I R
撰寫報告A R
問卷調查當責矩陣R:負責A:當責C:諮詢I:知會

工具評量
各種管理工具圖表介紹及應用
• 故障樹/ QC七大手法/品質機能展開/失效模
式影響分析
• 損益平衡/風險機率
• 甘特圖/技能矩陣/利害關係人
• 路徑圖/商業模式設計
• 投入產出/概念扇形/雷達圖/力場分析/心智
圖/強迫組合

89
總結
• 產品開發的失敗往往是人的因素，很少是技術因
素
• 致勝的七把鑰匙：
 承諾新產品開發的必要資
 無懈可擊的產品
 適當的組織架構與企業文化
 衡量並配合企業的核心能力
 考慮市場吸引力
 合理地強調速度的重要性
 瞄準全球市場
• 產品經理須有企業家格局

後續
異業合作
商業模式
設計
新產品開
發六大知
識領域
三年七萬，學習不斷
Face Book 社群
主題:
新產品開發/ 專案管理/ 行銷策畫
目的:
資訊分享/ 異業合作

Project
Impact
Portfolio Screen /
Investment
Commitment
Criteria
Deliverables Proceed To
Gate 3
Stage-Gate Framework
Facilitation
by Process
Manager
Research & Technology
Incremental / Development & Enhancements
NPD Stage-Gate Framework
Proceed
Champion
CONCEPT
FEASIBILITY
ASSESSMENT
Risk Profile
Criteria
Gate 1 Stage 1
Commercialization
Feasibility Criteria
Deliverables Proceed
Gate 2
Terminate Terminate
BUSINESS CASE
ANALYSIS
Basis for
decision
Post-
Mortem
Post-
Mortem
Terminate
Basis for
decision
Post-
Mortem
Stage 2
Basis for
decision
Full
Development
Organizational
Learning
--------------------
Cont-i-nuous
Improvement
TEAM
FORMATION
/PROJECT
RISK REVIEW
Stage 0
BMT BMT BMT
SPT
Cross Functional
Team
Selected
New Concept
Recycle Recycle Recycle
Cross Functional
Team
Cross Functional
Team
May be completed in Front end
Terminate

行動數位時代與商業發展趨勢

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie 行動數位時代與商業發展趨勢

Ähnlich wie 行動數位時代與商業發展趨勢 (20)

Mehr von jongminshi

Mehr von jongminshi (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (14)

行動數位時代與商業發展趨勢