## Anapaln Level 2
###### tags: `Anaplan`
### Introduction

#### Anaplan's New Modeling Experience(NMX)

#### Project kick-off（PKO）
> Anaplan專案啟動會議（Project Kick-off Meeting）的流程和內容。

##### 會議的目標與目的
- 了解客戶需求： 釐清客戶為何選擇Anaplan，他們想要解決的問題，以及對專案的期望。
- 建立共同的理解： 讓客戶和Anaplan團隊對專案目標、範圍和流程達成共識。
- 規劃專案執行： 確定專案的時程、資源分配、以及工作流程。
##### 會議的內容
- 客戶介紹： 由客戶代表分享為何選擇Anaplan，以及他們希望透過Anaplan解決的問題。
- 團隊介紹： 雙方團隊成員進行自我介紹，確認每個人的角色和責任。
- Anaplan介紹： Anaplan團隊會簡要介紹Anaplan的功能和優勢，以及如何將其應用於客戶的業務流程。
- 業務流程分析： 針對客戶的特定業務流程進行深入討論，了解其痛點和改善目標。
Agile方法介紹： 解釋Anaplan在專案中採用的Agile方法，包括Sprint、User Story等概念。
- 模型設計： 根據客戶的業務流程，開始設計Anaplan模型的雛形。
##### 會議的流程
1. 客戶介紹： 由客戶代表分享選擇Anaplan的原因和期望。
2. 團隊介紹： 雙方團隊成員進行自我介紹。
3. naplan介紹： Anaplan團隊簡要介紹Anaplan的功能。
4. 業務流程分析： 深入了解客戶的業務流程。
5. Agile方法介紹： 解釋Anaplan採用的Agile方法。
6. 模型設計： 開始設計Anaplan模型雛形。
7. 深入討論： 針對模型設計、數據整合等細節進行深入討論。
8. 建立共識： 確保雙方對專案的理解一致。
##### 為什麼要這樣做？
- 確保專案成功： 透過詳細的溝通和規劃，降低專案失敗的風險。
- 提高客戶滿意度： 讓客戶了解專案的進度和成果，增加他們的參與感。
- 提升團隊合作效率： 透過明確的目標和角色分工，提高團隊的合作效率。

**WRITING GOOD USER STORIES**
如何寫出好的使用者故事

**Independent** - User stories should be independent from each other
- 獨立性：每個使用者故事應該都是獨立的，彼此之間沒有太大的關聯。這樣可以讓每個故事都能夠獨立完成，並且更容易估算工作量。
**Negotiable** - User stories are a starting point of conversation
- 可協商性：使用者故事不是一成不變的，而是一個對話的起點。在開發過程中，我們可以根據實際情況對使用者故事進行調整和修改。
**Valuable** - Needs to be of value to the customer
- 價值：每個使用者故事都應該為客戶帶來價值，也就是說，這個功能對於客戶來說是有用的。
**Estimable** - Developers need to be able to estimate priority of story
- 可估算性：開發人員應該能夠對每個使用者故事的工作量進行估算，以便排定優先順序。
**Small **- The longer a user story, the greater chance of errors in scoping and estimation
- 小而精：使用者故事應該盡量簡短，這樣才能更容易估算工作量，並且減少在範圍和估算上的錯誤。
**Testable** - A story needs to be testable for the "Confirmation" to take place
- 可測試性：每個使用者故事都應該是可以測試的，這樣我們才能確認這個功能是否實現了。

#### Agile in Action

### Sprint1

#### Data Hubs
數據從外部來源收集後，會被匯入帶**數據中心DATA HUB**。
在Data Hubs，Data可以被**清洗refined**、**標準化standardized**，然後**傳遞**給Anaplan系統中的其他模型。
這些模型有時候被稱為**Spokes**


- Data hub 可以被設定執行 data mappings，以及各種提取extract、轉換transform、和載入load，又稱ETL
- 在ETL process，來自數據源的原始數據會被提取，讓後立即載入到data hub
- 一旦進入到data hub ，數據可以被轉換以適應業務需求，並輸入到spokes 模型以便在那裡使用
- Extract提取
- 從源頭讀取數據的過程。在此階段，數據被收集，通常來自多種不同類型的源頭。（可以包括其他系統、數據庫、平面文件或其他Anaplan模組）

- Transform轉換
- 轉換是將提取的數據從其原始格式轉換為輻條模型或模組使用的格式的過程。這是通過使用規則、查找表，或通過將數據與來自其他源的數據結合來實現的。這操作數據服務。輻條模型只接收它們執行其功能所需的數據。由於輻條模型不進行轉換過程，因此提高了輻條模型的性能。

- Load載入
- 載入是將數據從中心模型傳遞到輻條模型的過程 載入是將數據從中心模型傳遞到Spokes模型的過程

- 優勢
- Data hub是所有Spoke模型的單一資料來源。所有的transaction以及master data都會在數據中心進行更新和維護
- 數據中心還可以整合來自多個系統的數據。 This means所有模型都使用相同的數據

- 為什麼Data hub很重要？
- 由於數據中心是唯一的真相來源，數據中心團隊負責監督所有進入Anaplan生態系統的數據。
- 數據中心的管理和自動化是集中協調和執行的，這降低了錯誤數據進入系統的可能性，並提高了輸出數據的一致性。
- 這個數據中心團隊可以隸屬於業務部門，也可以隸屬於IT部門。
- 在數據中心內進行數據轉換和數據映射可以提升Spokes輻條模型的性能。處理數據的功能會消耗模型資源。因此，將這些功能放在數據中心執行，就可以避免在輻條模型中執行這些功能。所以，當發生大量數據事件時，輻條模型的性能不會受到影響。最終，這為在模型中工作使用者提供了更好的體驗。

- 將數據移入和移出Anaplan的內容，這稱為數據整合
- Anaplan提供了多層級的整合選項，從常見應用程式的環境，到命令列工具Anaplan Connect，甚至是REST API（應用程式程式設計介面），都涵蓋在內。

#### Delete from List using selection


執行這個動作會指示系統刪除那些使用布林值選取的項目。


這時候，會出現一個對話視窗。請使用正確的命名慣例來命名這個動作。由於這個動作會提供給最終使用者，所以我們會給它一個使用者友善的名稱：「刪除舊產品」。

在「從列表中刪除」欄位中，選擇要刪除的列表。在這個例子中，我們選擇了「產品扁平列表」。


「選擇使用」這個選項會告訴系統要使用哪個布林值來決定哪些項目需要刪除。請注意，在這個下拉式選單中，你只能看到與所選列表相關的布林值格式的行項目。

一旦動作被建立，你可以選擇：

- 個別執行： 直接在「動作」頁面中執行這個動作。
- 納入流程： 將這個動作整合到一個更大的工作流程中。
- 添加到使用者介面頁面或傳統儀表板： 將這個動作的按鈕或連結放到使用者介面頁面或傳統儀表板中，讓使用者可以直接觸發這個動作。

#### Model-to-Model Imports
當從不同的模組匯入數據時，可以從一個列表或一個已保存的檢視中匯入。
準備好的數據會大大提高模型在加載過程中的速度和性能。
因此，我們總是建議從已保存View中匯入



一旦資料載入完成，匯入的資訊就會顯示在「Action」設定下。關於這次匯入的詳細資訊會顯示在這些分頁中。你可以看到資料的來源標籤、類型、目標物件，以及其他有用的資訊。

你也可以點擊模型設定欄上的「來源模型」圖示，查看當前模型連接了哪些其他模型。

如果這次匯入只是臨時的，建議您將這個動作刪除。如果未來還需要再次進行相同的匯入，現在可以更改這個動作的名稱，方便日後辨識。此外，您還可以將這個動作添加到一個流程中，只要選取該流程，點擊「編輯」，然後從左側列表中添加這個動作即可。

- 請注意，Anaplan 平台只能「拉取」資料，不能「推送」資料。
- 這意味著，您只能從 Spoke 模型執行匯入動作，將資料「拉」過來，而不能嘗試將資料從 Hub 模型「推」過去。因此，我們建議您使用資料整合選項，例如 Anaplan Connect，來排定匯入任務，讓系統在夜間自動執行。
- 此外，很重要的一點是，我們展示的是一個匯入動作，而不是在行項目中引用公式。因此，如果 Hub 中的資料發生變化，Spoke 中的資料不會自動更新。您必須執行一個動作，將新的資料從 Hub 拉取到 Spoke 中。

#### Setting Default File on Imports and Exports

In Anaplan, when importing or exporting a file, you have the option to set the default file. Setting a default file for imports or exports is a form of security – it designates who can see and use the file.

設定預設檔案是一種設定安全的方式。換句話說，設定哪些人可以看到並使用這個檔案。「檔案」是一個重要的區別——我們談論的是誰可以查看和使用檔案，而不是資料。

一旦檔案中的資料載入到模型中，具有適當角色或選擇性存取層級的人就可以查看，無論為預設檔案選擇了哪個設定。

當終端使用者從 UX 頁面或經典儀表板執行匯入時，他們必須始終上傳個人副本的匯入檔案，無論是否存在用於檔案匯入資料來源的預設檔案。

一旦資料已匯入 Anaplan，更新您本地電腦上的檔案將不會更改已上傳的檔案。您必須再次上傳此檔案。



- No（keep private）
- 當系統管理員上傳源檔案到模型設定中時，或是任何使用者透過 Anaplan API 上傳檔案或在流程中執行檔案匯出動作時，就會產生這樣的檔案。
- 當您選擇 No (keep private) 時，該檔案就變成了私人檔案。私人檔案僅供上傳或匯出該檔案的人使用，而且僅限 48 小時。
- 48 小時後，這個私人檔案就會消失。然而，系統中可能還存在其他透過其他選項建立的檔案。因此，使用者可能會誤以為自己正在重新匯入自己的私人檔案，但實際上他們匯入的是另一個不同的檔案。
- 此外，如果您使用第三方整合程式，即使該程式聲稱可以將檔案的存取權限設定為「所有人」，但上傳的檔案仍然是私人的。

- Admins only
- 設定為「僅限管理員」的檔案，只有上傳或下載這個檔案的使用者，以及平台上的所有工作區管理員才能存取。其他一般使用者將無法存取這個檔案。

- Everyone
- 選取這個選項後，所有工作區管理員以及具有適當角色的一般使用者 都可以存取這個檔案。

管理員在上傳新檔案時，必須更新檔案的存取權限。 如果沒有這麼做，可能會導致其他人在平台上工作時遇到問題。


#### Create a process with multiple imports
一個流程（Process）在Anaplan中是一系列動作（Actions）的組合。你可以從模型設定欄（Model Settings bar）中的動作內容面板（Actions content pane）來建立、編輯和執行這些流程。


當你執行一個流程時，Anaplan會按照你指定的順序執行流程中包含的所有動作

##### Actions versus Process
- Actions
- Anaplan模型中執行的單一、具體的任務
- 通常用於執行個別操作，例如測試時的手動出發或一次性的任務
- Process
- 多個Actions的集合，按照設定的順序執行
- 用於自動化執行一系列Actions，以簡化工作流程
- 通常用於重複性的任務，可以通過Anaplan Connect 、API或用戶界面觸發

為何使用Process而非Actions?
- 簡化工作流程，減少錯誤
- 將相關的動作整合到一個流程中，能讓使用者更清楚地了解整個工作流程，並確保這些動作按照正確的順序執行。
- 就像組裝樂高一樣，如果按照說明書的步驟一步一步來，就不容易組錯或漏掉零件。
- 如果把流程設定好，就不用擔心會忘記執行某個步驟，或是因為執行順序錯誤而導致數據出問題。

- 方便修改，提升效率
- 如果流程內容有變更，只要修改流程本身，下次執行時就會自動套用新的流程。
- 例如，你想要在流程中新增一個動作，或是調整動作的執行順序，只要直接在流程中修改就可以了，不需要重新發布整個模型。
- 這就像在寫程式時使用函數一樣，只要修改函數內的程式碼，呼叫這個函數的所有地方都會自動更新。

- 保護Action，避免誤刪
- 流程中的動作受到保護，不能直接刪除。**如果要刪除某個Actions，必須先將它從流程中移除**。
- 這就像把重要的文件放在檔案夾裡，想要刪除文件時，必須先從檔案夾中取出，才能刪除。
- 相較之下，個別的Actions很容易被不小心刪掉，尤其是當模型中有大量動作時。

##### Process可以包含以下類型的Actions：
- Imports 匯入：將資料從外部引入系統。
- Exports 匯出：將系統內的資料輸出到外部。
- Deletebfrom list using selection 使用選取刪除：從列表中選擇特定項目並刪除。
- Bulk copy 批量複製：一次複製多個項目。
- Order list排序列表：對列表中的項目進行排序。
- update current period 更新當前期間：更新系統中當前的時間或期間。

> 請注意，涉及編號列表(numbered lists)的action（例如：建立、指派、只指派、複製分支、刪除分支）不能放在流程中。

##### Create a process



##### Classic Dashboard - publish and run a process





遵循Anaplan的流程最佳實踐，讓您的模型更有效率。
- 首先，將動作放在流程中，而不是單獨發布。
- 其次，將每個流程中的動作數量保持在最低限度。流程中的每個動作都會觸發模型的重新計算，因此只包含對流程必要的動作。
- 第三，為使用者面臨的流程使用「友善」的名稱，因為這些名稱會顯示在儀表板的啟動按鈕上。此外，對於數據中心或管理流程，使用數字前綴來表示流程的順序。

#### 1.3.13 Numbered List Actions
List membered
- 是 Anaplan 自動為每個列表項目分配一個獨一無二的系統編號作為名稱的一種列表


使用Numbered List的主要原因
- 避免重複名稱
- 可能會有名稱相同的情況
- 名稱長度限制
- 在標準列表中，項目名稱的長度最多只能有60個字元
- 使用者操作
- User 可以直接在dashboard上新增或刪除報表項目，標號會自動生成或更新

Numbered List versus. Standard List

如果modle不需要這些reason 可以使用standard list
**standard list**:
1. 雙重識別：允許為每個列表成員設定兩個獨特的識別碼：名稱和代碼
2. 資料匯入的彈性：當進行資料匯入時，可以根據名稱或代碼來匹配資料，使資料匯入的過程更加靈活，減少錯誤發生的可能性
3. 使用者控制：User可以自定義列表成員的名稱，這有助於提高資料的可讀性，方便管理和維護

**numbered list**:
1. 單一識別：編號列表只能使用系統生成的編號作為唯一識別碼，使用者無法自行定義名稱
2. 資料匹配的限製：在資料匯入時，只能根據編號進行匹配，如果編號有誤或發生改變，就可能導致匹配失敗
3. 可讀性較差：編號通常是一串數字，缺乏可讀性，不易理解列表成員的意義

編號列表結合Action可以提供給使用者標準列表沒有的功能
Action available only for numbered list:
- **Create**
- **Assign**
- **Assign Only**
- **Copy Branch**
- **Delete Branch**

##### Create
讓一般使用者可以新增項目到一個編號列表中
1.去 Dashboard建立一個新的dashboard
2.回到Action 建立New action 選擇Create（只有number list可以被選擇建立action ）
3.重新打開dashboard，可以新增data

##### Assign

允許使用者為一個或多個子列表成員指定一個父列表成員。在這個動作的術語中，被指定的是子成員

層級結構中的子層級必須是numbered list，且必須包含一個list-formatted property，例如顯示名稱。父層級可以是有序列表或標準列表。在使用「指派」動作之前，父列表成員和子列表成員都必須已經存在於層級結構中。

一些使用者可能會使用「指派」動作的例子包括：

- 將區域指派給業務代表
- 將人員指派給專案
- 將產品指派給工廠
- 將產品指派給客戶

practise

##### Assign Only

「僅指派」動作的工作方式與「指派」動作完全相同，但它帶有一個重要的限制：一旦端使用者啟動「僅指派」動作，就**不能取消指派子列表成員**。

這種方式在需要建立單向流程的情況下非常有用。例如，如果您不希望使用者在將列表成員添加到父層級後再移除它們（例如，作為批准流程的最後一步），您可以提供一個啟動「僅指派」動作的按鈕，而不是「指派」動作。這樣，批准者可以擁有另一個使用「指派」動作的按鈕，以便他們既可以添加也可以移除列表成員。


##### Copy Branch
在列表的樹狀檢視中，從選定的層級開始，一直延伸到該層級下最底層的所有內容，我們稱之為一個分支。

「複製分支」這個動作與「建立」動作類似，但功能更強大。除了可以複製層級中的單一項目之外，使用者還可以複製整個分支，包括該項目下的所有子項目，甚至可以複製包含該項目在內的所有上層項目。

要使用「複製分支」功能，被複製的列表項目必須屬於一個編號列表，並且必須有父項目。此外，整個分支中的所有下層項目（例如，該項目的直接子項目、孫子項目等）也必須是編號列表。我們不能複製整個層級結構的最頂層。

舉個例子，在我們的示範模型中，使用者可以啟動「複製分支」動作，複製整個專案結構，包括專案角色以及指派給這些角色的團隊成員。或者，使用者也可以只複製專案及其角色。


##### Delete Branch

#### 補充回顧 Time Rnages
- Dimension Type
- 時間範圍是一種維度類型，允許您建立包含比主要時間尺度更長或更短時間週期的模組或行項目。 時間範圍的單位是年，並且可以配置為任意多年的長度。 例如，如果您想分析過去十年的銷售額，您可以建立一個包含過去十年時間範圍的模組。 您設置的時間範圍可以根據您的需求進行配置 - 一個長達10年的單一時間範圍、10個每個長度為一年的時間範圍，或者一些組合。
- 時間範圍可以開始於主要時間尺度之前Before、延長至其之後Extend after或存在於主要時間尺度內Exist within the main timescale ，也可以完全存在於主要時間尺度之外Exist completely outside。 在下面的圖像中，會計年度從1月開始，12月結束，模型日曆包含FY 21至FY 23
- 
- 
- 
- 優點和限制
- 
- 
- 

- Step of time ranges
- 
- 
- 
- 
- Save

- 編輯Time Ranges
-使用「編輯」功能可以對時間範圍進行修改。大多數修改不會導致數據丟失（例如，更改聚合類型），但請注意，更改週期數量可能會導致數據丟失。例如，如果您的模組中包含一個具有三年時間範圍的數據行項目，而您將時間範圍編輯為兩年，那麼不再與時間範圍對齊的那一年數據將被移除。
- You can edit the Name, Start Period, Number of Periods and Available Aggregations. When you are finished, click Save Time Range. Remember that data from a time period that is removed is erased.

- Deleting Time Ranges
- 在刪除一個時間範圍之前，必須先將所有引用該時間範圍的模組和行項目中的引用移除。 在每個使用該時間範圍的地方，您需要選擇一個不同的時間範圍或模型日曆，或者直接刪除該行項目或模組。

Aggregation
> Aggregation = Sumary Levels

- 您可以選擇如何彙總（或總結）每個時間範圍。這個設定會決定在行項目或模組中顯示哪些「摘要欄位」。當您新增或編輯一個時間範圍時，就會選擇這個設定。彙總方式包括：季度總計Quarter Totals、半年總計Half-Year Totals、年初至今Year to Date、年終餘額Year to go和所有期間總計Total of all Periods。
- 模型日曆的彙總會預設包含，因此您的模組或行項目將同時包含日曆彙總和時間範圍彙總。
- 
- 當您在一個行項目中啟用了一些尚未包含在模型中的彙總層級時，這些彙總層級就會在將時間範圍應用於該行項目時自動添加到模型中。請注意，這可能會導致使用 PARENT 函數時，時間週期格式的行項目返回與預期不同的結果。
- 例如，對於 2022 年 1 月的數據，公式 Name(PARENT(item(time))) 如果沒有啟用季度彙總，則會返回 FY22（2022財年）。但如果啟用了季度彙總，則結果會是 Q1 FY22（2022財年第一季度）。

Granularity粒度

> Granularity = Level of detail
- 粒度是什麼？
- 粒度簡單來說就是數據的細緻程度。就像我們看地圖一樣，可以看世界地圖、國家地圖、城市地圖，越詳細的地圖，我們看到的細節就越多。在數據分析中，粒度也是一樣的道理
- 

向模組添加時間範圍
直到您將時間維度拉入對話框的清單和匯總區域，時間範圍才會顯示出來

在Line Item 添加時間範圍

如何選擇 Model Calendar / Time Ranges？

#### Createing Codes for Attributes

您可以在數據中心的一個系統模組中建立標準化的代碼。一旦建立，這些代碼就可以用於執行規劃模型中的函數，以填充屬性。
請注意，我們正在討論的這些代碼與匯入過程中使用的標準預設代碼不同。這些代碼是客製化的，用來幫助識別您的數據中的屬性。

### Sprint2
#### Model Design
傳統的模型建構方式是先從建立列表開始，接著加入模組，最後才考慮User Experience
比較有效率的方法是先從user experience開始
1. 確定使用者角色
2. 規劃使用者界面
3. 整合到業務流程
→先想清楚‘誰要用’以及‘要怎麼用’再開始建立模型

#### Model design process
1. 了解需求與技術環境：
- 理解需求： 深入了解客戶對於這個模型的期望和要求，包括功能、性能、數據等方面的需求。
- 技術環境： 了解現有的技術系統、數據庫、以及其他相關的軟硬體環境，以便將模型整合到現有的系統中。

2. 規劃使用者體驗：
- 不同角色體驗： 為每個使用這個模型的角色設計最佳的使用者體驗，包括操作流程、介面設計等。

3. 確定輸出模組與數據需求：
- 輸出模組： 基於使用者體驗設計，確定模型最終需要產出哪些結果或數據。
- 數據需求： 為了產生這些輸出，模型需要哪些輸入數據？這些數據從哪裡獲取？

4. 識別數據模組：
- 數據模組： 將所有需要的輸入數據和輸出數據歸類為不同的數據模組。

5. 識別使用者輸入：
- 使用者輸入： 確定模型需要使用者提供哪些輸入數據，這些數據將作為模型計算的基礎。

6. 確定計算邏輯：
- 數據轉換： 確定如何將原始數據轉換為模型可用的格式。
- 計算過程： 設計模型中的計算邏輯，即如何根據輸入數據計算出所需的輸出結果。
- 模組劃分： 將計算過程劃分為不同的計算模組和系統模組。

7. 建立模型架構：
- 視覺化模型： 使用Lucidchart等工具，將模型的各個組成部分（如數據庫、計算模組、輸出模組）用圖形的方式表示出來，形成一個清晰的模型架構圖。
- DISCO原則： 在建立模型架構時，要遵循DISCO原則（具體內容未在文中說明，可能是一個模型設計的最佳實踐指南）。

8. 設計檢查：
- 全面檢查： 在完成模型設計後，要對整個模型進行一次全面的檢查，確保各個部分的邏輯正確、數據流暢、功能完整。

##### 1. Understand the requirements and the customer’s technical ecosystem
**Purpose**: To solve a problem, you must completely understand the current situation. Performing this step provides this information and the first steps toward the solution. 為了解決問題，必須完整了解目前的情況。這個步驟提供資訊，並為解決方案邁出第一步

**Process**: When you begin a project, you gather information and requirements using tools that
include:

- 工作說明書（SOW）
- 定義專案範圍、目標、高層級需求
- 宣言（Manifesto）
- 說明專案的目標，也就是要達成什麼樣的成果
- IT生態系統圖
- 顯示哪些系統會提供數據給模型，以及哪些系統會接受模型產生的數據
- 問題與注意事項
- 
- 商業邏輯定義
- 模型中會包含哪些關鍵的商業邏輯？
- 解釋: 這個模型要模擬哪些商業上的決策、運算或流程。例如，一個銷售預測模型，其商業邏輯可能包含銷售趨勢分析、季節性因素調整等。
- 分散式模型需求
- 
- ALM工具的使用
- 
- 使用者故事
- 使用者故事是由使用者角度出發，描述他們需要系統提供哪些功能

> Result
> 

##### 2. Plan the end user experience for each role

**Purpose**: This is an important step in the model design process. Ultimately, the information or data that the end user needs to make a good business decision is what drives the entire structure of the model.這是模型設計過程中非常重要的一步。最終，使用者需要哪些資訊或數據來做出良好的商業決策，將決定整個模型的結構

**Process**: On some projects, you may be working with a project manager or a business consultant to flesh out the business process for the user. You may have user stories, or it may be that you are working on design a bit earlier in the process and the user stories haven’t been written. In any case, identify the user roles, the business process that will be completed in Anaplan, and create a high-level design of the user experience. Verify the design with the users to ensure that you have the correct starting point for the next step.
在某些專案中，您可能會與專案經理或業務顧問合作，共同為使用者勾勒出業務流程。您可能已經有使用者故事，或者您可能在設計過程中較早的階段就開始進行設計，而使用者故事尚未編寫。無論如何，請識別使用者角色、確定在Anaplan中將完成的業務流程，並建立使用者體驗的高階設計。與使用者驗證設計，以確保您為下一步奠定了正確的基礎.
**前置到後置的設計方法**已被確認為模型設計的首選方法。 這種方法將重點放在最終使用者體驗上，使使用者能更容易適應模型。在這個步驟中，我們將聚焦於：

- Document the process
- 
- 
- 
- 


#### Designing for usability

「可用性」這個領域已經發展到非常成熟的階段，有許多相關的標準和專家。可用性指的是產品使用起來的難易程度，也就是說，使用者能否輕鬆有效地達成目標。可用性評估主要關注使用者在使用介面時遇到的困難。這篇教學會提供一些專門針對Anaplan平台的可用性指南。

建構UX頁面 請遵循以下指引
1. KNOW YOUR USERS
- 為了創造最佳的使用者體驗，你需要與你的使用者合作，以了解他們的需求。在模型設計過程中，你已經創建了使用者體驗的草圖或線框圖
- Before you start building UX pages for the end user, vertify that the sketches are still accurate.在你開始構建UX頁面之前，請驗證這些草圖對於最終使用者來說是否仍然準確。 在構建過程中，持續與使用者確認，確保你走在正確的道路上。最後，透過觀察使用者來測試你的頁面，找出任何可用性問題。
- UX頁面應該針對不同群組的使用者進行設計，具體取決於他們的需求。使用你在模型設計過程中識別出的角色，確保在設計過程中與使用者確認，以防遺漏任何角色。
- 找出使用者通常如何訪問Anaplan。 他們是使用平板電腦、筆記本電腦還是行動裝置？

2. Call to Action
- 當你在設計規劃頁面時，最好採用「呼籲行動」（Call to Action）的方式。 這意味著要清楚地指出使用者目前面臨的問題，並提供明確的解決方案，引導使用者採取行動。

3. Organizing the Elements
- 將UX頁面上的元素進行組織，讓使用者更容易理解數據，並學會如何使用這個頁面。考慮到業務流程，將頁面安排成符合自然流程的順序
- Consider the business process. Arrange the UX page to match the natural order and flow of the business process.

- Important information at top
- 當使用者與UX頁面互動時，他們希望一眼就能看到最重要的資訊，以便了解他們計畫目前的狀態。 我們建議將關鍵績效指標（KPIs）和摘要數據放在頁面上方.
- 將這些資訊放在頁面上方，有助於使用者專注於結果，並清楚地顯示先前決策的效果。請優化頁面，只包含評估數據所需的信息，以縮短決策時間
- 

- Present data in digestible Chunks
- 另一種組織數據的方式是將其分段呈現，讓使用者更容易消化。如果頁面上塞滿了大量數據，可能會讓使用者感到 overwhelmed。為了避免這種情況，可以先提供高層級或摘要性的資訊，並附上連結指向詳細數據。從簡單的數據開始，只有在需要時才增加複雜度。這種方式稱為漸進式揭露。
- 你可以將卡片中的摘要數據連結到工作表中的詳細數據。在工作表中，你可以使用洞察面板中的快速連結，將使用者導向其他頁面上的有用資訊。此外，你可以使用「額外洞察」來存放有用的但次要於主要數據網格的項目。
- 

4. Visual design
- Group data into categories
- 有些時候，我們需要呈現大量的數據。在這種情況下，我們應該將數據分組（分成容易理解的小塊），這樣使用者才能清楚地了解各個數據之間的關係。在應用程式的內容頁面上，將頁面分為不同的類別；在頁面內，將相關的數據放在容器中，並使用文字卡片來創建標題。
- 

- Visual load challenge question
- 減少使用者的視覺負擔。頁面應該看起來乾淨整潔，如果頁面上有太多選項，而且這些選項的層級看起來差不多，可能會導致使用者很難做出決定
- 如果頁面有太多元素可以考慮將頁面拆分
- 

- Consistency 一致性
- 
- 

- Graphic Elements
- 
- Which of these graphic elements are NOT used to compare values over time?那些圖形元素不適合用來比較隨著時間變化的值
- Bar chart條形圖/ Pie chart
- Which graphic element is best the used to display part-to-whole relationships with multiple components(for example: salary,benefits,travel,marketing and overhead costs) and how they impact the whole(for example: total costs) over time?哪種圖形元素最適合用來顯示多個部分組成一個整體的關係，以及這些部分如何隨著時間影響整體（例如：薪資、福利、差旅、行銷和管理費用如何影響總成本）？
- Stacked column chart
- 

5. Instructions
- 使用者體驗應該包含指示和幫助，說明如何使用這個 UX 頁面。
- 指示應該清楚簡潔。使用的語言應該讓使用者容易理解
- 如果組織有一個叫做「庫存週轉率」的關鍵績效指標 (KPI)，用來追蹤庫存週轉的速度，那麼在 UX 頁面上就應該用「庫存週轉率」這個詞，而不是用其他相似的詞。
- 如果組織使用的術語並不清楚怎麼辦？在設計頁面時，要考慮到人員流動。新的員工可能會加入組織，所以現有員工熟悉但新員工不了解的詞彙可能會造成混淆。
- 可以考慮加入文字卡片來提供指示或一般資訊。使用卡片提示來解釋圖表或其他視覺化元素中的數據。

- 

- Provide user visibility into status
- 使用者體驗應該始終保持使用者知情，透過適當的回饋，在合理的時間內。了解當前的狀態能幫助使用者決定下一步該做什麼，並幫助他們判斷自己的操作是否有效。可以考慮在說明中加入資料輸入如何影響 UX 頁面上的其他資料。
- 
- mobile
- 如果這個角色有很高的機率會在行動裝置上頻繁使用 Anaplan，那麼在設計頁面時，就應該以行動裝置的使用者體驗為優先考量。那些包含大量資料和巨大表格的頁面在行動裝置上使用起來會很困難，所以最好避免這樣的設計。將文字卡片標題設置為橫跨整個頁面，這樣它們在行動裝置上顯示時會更正確。
- 

Working with End Users

- 
- 
- 
- 
- 

Tips and Tricks Categorise
- General Tips
- Navigation Tips
- Avoid horizontal scrolling
- 請避免儀表板整體需要水平捲動。將模組垂直排列會更好。在表格內進行水平捲動是可以的
- Add page selectors rather than module selectors
- 建議您使用模組的「檢視」選單中的「發佈頁面選擇器到儀表板」選項，將頁面選擇器添加到經典儀表板，而不是使用模組的頁面選擇器
- 
- Buttons to avoid
- 

- Filtering Tips
- Don't filter when initially publishing a chart
- 如果圖表有一個過濾軸，在發布前請將過濾器設定為顯示所有項目。
- 發布後，您可以將過濾條件設置回原來的狀態，圖表就會按照新的過濾條件顯示
- Efficient filters
- 為了達到最佳效能，每個圖表的每個軸都應該只包含一個boolean條件的篩選
- Use separate modules for filters
- 將篩選條件設置於獨立的系統模組中。這些篩選條件可以重複用於不同的模組
- Use time filters
- 不要使用顯示/隱藏功能來處理時間，而是建立並使用一個「時間設定」模組來篩選模組。
- 這樣做會讓篩選變得動態，也就是說，當模型日曆變更時，篩選結果也會跟著改變。
- Filter in order of size
- 

- Avoid filtering on nested dimensions
- 

#### Thinking Through Yout Formulas

How do you determine which formulas to use? This lesson will help you think through your model's formulas.
- 
- 
- 

1. Frist Step

2. Second Step

首先，用一句簡單的話描述公式的功能。如果句子較為複雜，將其拆分成更小的部分。Engine在處理較小、獨立的計算時效率更高。
- 將複雜句子拆分：
- 將一個複雜的公式所要表達的邏輯拆分成幾個簡單的句子。這樣可以讓問題更清晰，更容易理解
- 將簡單的句子轉換成Anaplan公式
- 將每個簡單的句子對應到Anaplan中的具體公式。Anaplan提供了一系列的函數，可以幫助我們實現各種計算邏輯。


- Duplicate Calculations？
- 我們在建立模型時，如果發現需要進行某個計算，應該先檢查一下之前是否已經定義過類似的計算。如果已經有現成的計算，就不用再重新寫一遍了，直接引用就可以了。這樣做的好處是，可以避免重複造輪子，提高工作效率。
- 依照之前PLANS規則中的N
- necessary: Don' duplicate expressions. 不要重複表達式，數據和屬性只需儲存一次，然後多次引用。不要在超過需要的維度上進行計算

- Draw Intermediate Calculations
-