資料來源、函式、圖表、輸出格式及管理機制都是競爭重點
過去報表工具的選擇很少，多數企業是手工開發報表程式，後來開發工具開始搭配報表設計工具，提供報表元件，以協助企業解決報表需求，其中以Crystal Report最為常見。
由於Web化的趨勢，催化報表的發展，企業開始希望取得即時的內容，因此報表開始多元發展，不再拘泥於印表及文字型式，變化出PDF、HTML、Excel及CVS等輸出格式，且包含各種分析圖表（Chart）朝圖文並茂發展。在短短近兩年的時間，市場陸續引進國外的報表系統，本土廠商研發自有品牌的報表產品。
功能細緻度有差別
報表的需求一直都存在，只是像Crystal Report及JReport等，頂極的產品價格不低，因此一般企業難有意願花錢購買工具。當報表的應用因Web的推動而更加普及，市面上符合各種企業層級的產品便應運而生。
報表產品的價差，除了因為本土及外商有差別，其實跟產品的功能細膩度有關係，因此貴有貴的道理。從報表工具的基本功能來看大同小異，但詳細深入每一個環節，就會發現應用上的彈性仍有差別。
大致上，報表系統競爭的重點在於支援資料來源、函式、圖表元件及輸出格式的多寡。其次包括支援的平臺、排程、大量列印、身份管理機制能否與既有的LDAP或資料庫結合，最後再衡量執行效能。
平心而論，國外引進的報表產品，系統的擴充彈性較大，但相對價格較高；本土廠商研發的產品，未必具有調整的彈性，但用心於使用者介面的親和性，所以各有不同的特色，都是很好的賣點。
大部份的報表，最廣泛應用的資料來源是資料庫，應用的函式以加、減、乘、除、加總、小計最常見，圖表則以圓餅圖、長條圖、曲線圖等為主。如果企業沒有特殊的應用，那麼本土廠商瑣定市場大宗功能，夾帶低價策略，並提供中文化的親和介面，再針對不同族群提供符合需求的功能，就是具有競爭優勢的產品。
資料來源發展多元
為了提供直覺的設定機制，報表工具均利用精靈化的導引步驟，協助使用者連結資料來源，並選擇報表所需的欄位，可說是圖形化的SQL，並容許使用者修改內容或增加虛擬欄位，由工具自動產生對應的SQL陳述式。
產品之間的差別就在於資料來源的多元性，及能否同時存取多個資料庫的能力。支援各種關聯式資料庫是基本的要求，此外，還包括文字檔、CSV、Web Services、XML等格式，Java應用程式選擇報表工具，可能需要界接EJB或CORBA等資料來源。
企業若需接收其他特殊資料格式，即須檢視報表工具是否提供自訂的彈性。JReport提供UDS（User Data Source）的功能，即可讓開發人員自訂資料格式，接收特殊資料來源，威技資訊軟體工程師陳建綱表示：「接觸最特別的案子，是接收Socket的資料。」
除了支援多種資料來源，能否在同一支報表存取多個資料庫，也是目前報表工具會被比較的功能，因為報表所需的內容，可能來不同的資料庫。從實務的角度陳建綱分析：「這是一種取捨，同時存取多個資料來源必會犧牲效能；彙整不同來源的資料到單一的資料庫，的確可以取得較好的效能，但卻無法兼具即時性。」也就是說沒有絕對好的解決方案，應視情況選擇合適的方法。月報、季報等資料不易再變動的報表，便適合彙整並另存資料到單一資料庫，以取得最佳的效能；如果必須取得最即時的資料，勢必要犧牲效能。設計介面也強調親和
報表設計首重簡易及直覺，所以觀察各家設計工具的圖形使用者介面，會發現與Word及小畫家的組合類似。如果畫面拖拉不夠直覺，就會造成使用者的排斥感。
此外，報表設計競爭的重點，在於圖形元件及函式的多寡，企業的需求千奇百怪，為了符合各種產業的需求，仍需保留客製化的彈性，讓客戶可以匯入外部的圖形元件，或自行設計函式。李日貴反思：「設計介面強調函式的豐富性，倒未必是絕對優勢。」因為資料匯入Excel之後，就有各種函式可以選擇，也可以自訂。
聯銓資訊整合Excel提供報表設計機制，其優點就是可以不必自己開發運算函式，運用現成的Excel函式，即可滿足企業的需求。更重要的是，報表需求最多的財務會計部門的商務使用者，對Excel的熟悉度遠勝於開發人員，因此聯銓強調Smart Query是提供商務使用者設計報表的工具，可大幅減低開發人員的負擔。
也許這樣的創意缺乏原創性，不過，Smart Query的用戶日盛金控，反而認為客戶在乎的重點是快速開發，因此反而認為結合Excel是很有創意，可大幅減少學習的成本。企業較擔心的問題，是報表設計檔是否因為Excel版本的不同，而出現不相容旳情況？聯銓澄清，Smart Query儲存設計檔為XML格式，所以不會因為Excel版本不同而受到影響。
簡易直覺的設計工具是目前的趨勢，讓沒有技術背景的商務使用者，可以不假專業人士之手，依需求設計報表格式。不管報表設計工具是模仿還是原創，最重要的目的都是提供容易使用的介面。
另一個設計階段的重點，是提供預覽功能，因為預覽功能讓設計人員即時檢視執行後的結果，確保設計無誤，可以加快開發的效率，重點就在於預覽時期與執行時期兩者的精準程度，如果預覽時模擬的報表與真正產出的報表有差異，就不夠精準。
聯銓的Smart Query提供兩種測試方法：整合測試是自網站登入及權限審核到報表呈現的完整過程；查詢測試僅測試查詢功能。也有產品例如騰蒙的Report Sonic的測試功能，就是直接啟動相關軟體，產出Excel、PDF或HTML檔案，就沒有模擬精準度的問題。
輸出多元、排版精美才夠看
企業報表應用非常多元，輸出格式的多樣性，也是比較的重要項目。常見的形式包括HTML、PDF、Excel、套表列印或直接由印表機電子郵件、傳真輸出，也可能設定排程定時製表輸出。
報表的輸出可能透過伺服器印表，也可設計下載結果至用戶端，由使用者決定如何輸出。大量資料的列印或套表，例如對帳單或交易明細表，選擇伺服器列印可以取得比較好的效能；統計及分析數據比較適合由使用者自行決定輸出格式。
此外，樣式的精緻度，可看出設計工具的用心，圖表的應用及樣式的編排，可增加版面的豐富性。越精細的微調機制，例如字型、大小、欄位對齊、頁首、頁尾及圖表的設定，都可強化報表的質感。PowerBuilder的專利技術DataWindow，提供細緻便利的報表排版功能，令人印象深刻，而今在許多報表設計工具，都可以看到DataWindow的影子。真正的標準應在輸出/入端
當企業決定導入報表解決方案，既有的報表如何處理便成為頭痛的問題，手工寫程式製作的報表無庸置疑勢必要重新設計，如果是Word檔設計供企業內部手寫的表單，騰蒙Report Sonic的設計工具支援DOC格式，可延用設計格式，只需定位資料庫欄位，以套用內容。
除此之外，開發工具以Crystal Report的應用最普及，所以JReport、Report Sonic、Crestal Clear等產品，強調支援讀取或轉換Crystal Report報表設計檔RPT專屬格式。
伺服器可以解讀Crystal Report設計檔，原來的報表無需重製；JReport的作法是提供Crystal Report的轉換器（Converter），好處是轉換成JReport的設計格式，比解譯RPT檔擁有較佳的效能，不過由於Java與Windows技術有差異，部分OLE物件或統計圖表無法100%精確轉換，所以仍須微調。
目前也有廠商將設計檔訂為XML格式，企業開始思考未來會不會出現標準的設計檔格式，以避免工具之間互不相容，導致企業必須重新設計的麻煩。
李日貴認為：「真正的標準是輸出及輸入端，而非設計檔。」為了侵蝕競爭者的市場，設計檔必定會相容於大廠。報表輸出檔雖未統一成單一標準，但除了直接印表，已可固定輸出為PDF、HTML、XLS、CSV等格式的趨勢。
輸入格式指的是套用的資料格式，例如XBRL（Extensible Business Reporting Language；延伸商務報告語言）即財務資訊、報表與資料分析等領域，基於國際互通性的考量，針對商業報告所發展的標記語言，以利資料交換與轉換。
助於報表多元應用
工具都願意為好的整合開發環境作銜接（Plug-In），Windows開發工具多搭配Crystal Report；Java市佔率最高的JBuilder也內建Crystal Report，不過也可搭配Style Report、JReport或Crystal Clear，其他例如WebLogic或WebSphere，可整合的工具仍限Crystal Report或開放原始碼工具。
報表難免必須與應用程式互動，所以一定要有與程式接軌的窗口。開發工具可內建的報表工具，的確可以增加開發的便利性，不過報表工具即使未與開發環境相結合，也都會提供API，以利與應用程式整合。所以API的豐富性，應該比報表設計工具能否與開發工具結合更重要。
報表設計技巧攸關開發效率
從開發的效率及報表的品質分析，陳建綱建議設計人員設計前先確定使用紙張的大小，並善用範本，可以縮短開發時程。在設計階段精確選擇所需的資料，避免重複的欄位。
此外，利用圖表表達複雜的資訊，不但使報表不會流於單調，也可以提供管理者一目了然的分析結果。利用函式及參數可以增加報表的彈性，不但提供使用者更多元的資訊，也可減少資訊人員設計報表的數量。
伺服器管理機制
伺服器必須提供友善的管理介面，才有助於系統管理者的管控，權限管理首重能否與企業既有的資料或LDAP整合，設定使用者查詢及列印的權限，例如Smart Query的報表權限設定，可以指定使用者報表輸出的格式，一般使用者只能輸出PDF檔，避免竄改資料的疑慮。
不過，報表的權限控管透過伺服器設定，控管的基準以報表為最小單位。JReport除了在伺服器設定使用者權限，設計階段提供Security Controller，可依欄位設定讀取權限，例如人事部有權限查詢及列印員工基本資料報表，但是只有人事部主管可以看到薪水欄的內容，這是更細項的資料讀取權限控管機制。如果每一張報表都要逐一設定Security Controller又顯得太麻煩，而且權限更動時又得逐一修改，因此JReport的報表夾可根據連線使用者設定套用相同設定的範疇，就避免重複設定的麻煩。
排程是另一個報表系統重要功能，對帳單、交易明細、客戶資料等是常用需要大量列印的報表，但列印時間長，如果上班時間列印，可能影響其他工作的進度，利用排程功能在半夜離峰時間執行，即可有效運用時間及資源。此外，每周一次的主管會議、每月、季、年等會計報表，此類周期性需要的製表，也可以設定排程自動產生，減少人力的負擔。
透過傳真、電子郵件傳遞的報表，排程自動報行的工作，都有異常狀況發生的可能，異常通知就是必要的機制，回報負責人才有及早補救的機會。另一種異常通知機制，是使用者設定當報表的統計數據超出正常值時，自動通知主管或當事人，也就是紅綠燈機制，為管理者監控營運重要指標。
Reporting Services的衝擊
目前微軟推出的Reporting Services，只是依附在SQL Server的產品，短期內看起來，是為了增加SQL Server的附加價值，並整合Visual Studio .NET提供設計介面。過去Visual Studio系列的產品，皆整合精簡版的Crystal Report提供報表開發功能，未來可能會衝擊到既有的市場。
不過廠商未必抱持悲觀的想法，市場已習慣微軟利用既有的產品，包裝另一個免費奉送的未成熟產品的手法。雖然Reporting Services已具備基本的報表功能，但仍屬陽春的版本，且一定要搭配SQL Server才能使用。報表廠商認為真正需要報表產品的企業，仍希望選擇完整而成熟的解決方案。
短時間之內，Reporting Services首當其衝會影響到開發工具內建的報表設計工具，而且範圍限於Windows平臺的Visual Studio .NET開發者。未來Reporting Services成熟之後，市場預料微軟將開始收費，那即是另一個價格及功能的競爭。屆時Reporting Service免費內建於Visual Studio .NET 的優勢即可能浮現，開發者比較容易接受熟悉的產品，以減少學習的負擔。
Java廠商則認為市場區隔並不相同，Reporting Service瑣定Windows平臺，Java解決方案則具有跨平臺的優勢。如果企業存在多種異質平臺，選擇Java報表系統，是比較節省成本的方案。直式報表學問大
直式報表是東方社會的特殊需求，在作業系統、資料庫及開發工具都是西方世界的產物情況下，設計直式報表不是容易的技術。李日貴分析直式報表的難處：「中文字其實是長方形，當文字轉90度變成直書時，排版及換行就是很大的學問。」
在PowerBuilder上，每種字型都有兩種選擇，前面包含「@」的字型，即直書字型，所以沒有直式報表的問題。倍力資訊總經理室研發組副理張永松解釋：「Java本身的問題在於中文字串轉90度後，所有的字會疊在一起。」由於Java原本的機制無解，且中文字的排版會有位移的現象，因此不容易處理。
目前可以提供直式報表的廠商並不多，廠商也未必願意透露支援直式報表的技術底層。深耕Java技術的李日貴分析：「目前達成直式報表的技術可略分，將每個字變成圖再轉90度，及套用直式字庫兩種方法。」
把每個字變成圖檔後，再玄轉90度的技術最複雜，JReport即利用此種技術設計直式報表。使用者在設計階段設定好資料來源、字型及大小，系統自動把每個指定字型、大小的字都轉換成圖，再玄轉90度。
張永松表示，目前市面上有一個「FontLab」軟體，字型廠商可以利用FontLab將字轉90度，另建一個直式字庫，企業只要購買直式字庫，即可解決直式報表的問題。倍力資訊即建議有直式報表需求的客戶，尋求此類解決方案。
其實藉助其他軟體也可達到直式報表的目的，騰蒙科技即結合Word的功能，先以Word設計直書公文格式，再將DOC檔匯入Report Sonic的設計工具，在文件中設定資料庫欄位對應的位置，即可利用Word輸出直式報表，算是一種取巧又方便的解決方法。報表的效能解決方案
獨立的報表系統分散了既有系統的工作負擔，且提升報表開發的效率，對企業而言已是效能的強化。不過，當報表的應用日漸增多，伺服器啟用上百甚至上千支報表，通常同類的報表被查詢的時間都很雷同，所以可能造成執行的瓶頸。李日貴認為效能不是報表系統最重要考量，因為：「交易不能慢；分析不能錯。」所以企業不會針對報表及分析工具要求嚴苛的效能。
Java的效能問題在應用伺服器
以Java開發的報表系統，例如Report Sonic、JReport、Crystal Clear、Style Report及Crystal Report 10均強調百分之百Java開發，就是因為純Java開發的應用程式，除了有跨平臺的優勢，且程式執行無需再經一層轉換，不會折損效能。
Java系列的報表系統，大多是必須建構於J2EE伺服器之上，所以效能的問題多存在於J2EE伺服器的調校，目前Java系統的報表產品，唯獨JReport強調報表伺服器可以獨立運行，陳建綱說明：「伺服器與應用伺服器必須緊密整合，才有利於效能最佳化。」
當效能出現瓶頸時，可以從應用伺服器及報表伺服器兩方面著手調校，那麼管理人員必須兼具應用伺服器及報表伺服器兩者的技術，JReport內建Java引擎就可以降低維護的門檻。此外，JReport提供監控伺服器，包含報表程序、連線使用者及資料庫連線等效能資訊，是優於其他報表產品的效能監控方案。
報表設計應避免沈重的I/O負擔
從報表的豐富性角度來看，善用圖表、函式庫及交叉分析是設計重點，但從效能的觀點出發，這些卻恰恰是影響執行效率的罩門。智亞國際提供建議，一支報表不要關聯（Join）過多的資料表，如果需要多個資料表才能完成報表，改以另存資料於單一視景（View）是比較好的方法。其次，「Select *」雖然是很方便的存取方式，但會佔用太多記憶體空間，因此精確選擇所需的資料，篩選掉不必要的欄位，避免造成報表引擎的負擔。
此外，設計人員應善用處理器的運算能力，並注意資料輸出/入造成頻?的負擔。因此盡量使用SQL陳述式處理資料運算及型態轉換，因為資料庫在伺服器內部利用處理器運算速度很快，若透過固定的頻寬下載大量資料，到用戶端再套用公式運算，將浪費大量的輸出/入時間。
Borland大中華區技術總監李維也提出類似的建議：「大量資料的運算，應善用StoredProcedure，由伺服器執行，再回傳少量的結果至用戶端。」開發人員對效能的技巧不可不慎。過去利用ASP或JSP設計Web報表，設計不佳常造成執行逾時的狀況，就是因為資料傳輸量太沈重的原因。文⊙李延華
