目前，包括：智能小區、辦公大樓等都陸續將一卡通系統作為弱電的一個子系統進行規劃、設計、建設，應該說是智能卡應用發展的又一新趨勢，這令許多智能卡系統廠商大受鼓舞。這些擬定建設的一卡通系統基本包括：停車場系統、門禁系統、考勤系統、消費系統、巡更系統等。但是，這些項目大多數甲方都采取將一卡通系統打包到弱電總包中，由弱電總包方再轉包給一卡通工程商，一卡通工程商再選擇采用哪些智能卡系統供應商。
　　
　　首先我們承認，采用弱電總包有一定的好處，具體表現在以下幾個方面：
　　
　　*、可以便于確定工程責任
　　
　　在小區或辦公大樓建設工程項目中，弱電項目與土建、裝飾等相比總造價很低，但項目卻是zui多的，可以分為：綜合布線、背景音樂、消防、報警、監控、周界、一卡通等多個大項；而每個大項又分很多小項，采用總包方式，可以方便確定工程責任問題，甲方有任何問題都可以只找總包方，這無疑為甲方節約了時間，提管監管效益。
　　
　　第二、確保售后服務
　　
　　在弱電項目中，由于包含多種產品，每種產品的售后質保期是不*相同的，有一年的，兩有兩年、三年的。采用總包，甲方可以與總包方確定整個弱電項目統一的質保期，比如兩年。而總包方將自行核定實施兩年質保的維護成本，并將其打入總預算中去。
　　
　　第三、節省選擇的時間（甚至是一些盲目選擇的時間）
　　
　　畢竟，甲方的工程人員不可以在各個方面都比較了解，可以輕松的在國內眾多的供應商、工程商中進行合理而有效的選擇。事實上，這種選擇對甲方來說無疑是十分艱苦的事情。選擇弱電總包，只需著重在本地為數不多的大型工程商中進行實力、工程質量、工程服務等方面作一些比較，就較容易選擇合適的工程總包方。
　　
　　但是，我們認為，作為弱電項目之一的一卡通系統，不宜*采用弱電總包的方式進行。我們經歷了、也看到了很多采用這一方案之后產生的效果不佳的案例。
　　
　　這里我們舉一個例子是成都蜀漢路一個大型國有企業的辦公大樓一卡通系統吧。該項目采用的是弱電總包方案，總包方也算是成都有名的一家工程公司。一卡通項目包括：停車場、門禁、考勤、消費、巡更。后來實際上的項目包括：停車場、門禁、考勤；實際用上的包括：停車場、門禁；運行效果比較好的包括：門禁（只完*員*功能）。在這一項目中，大量采用了進口設備，如：門禁采用韓國STAR，停車場道閘采用意大利Nice，考勤機同樣采用韓國STAR。整個一卡通項目應該在100多萬吧。停車場系統采用紅外車輛感應技術，可是該抬閘不抬，該落閘不落；考勤機裝在大門口應沒有用過；食堂收費系統根本不敢用；門禁系統只能完成簡單的*功能；卡片供貨周期很長很長，很貴很貴……為什么會這樣呢
　　
　　我們認為問題的根源就在于采用了總包方式，層層轉包，層層的溝通不暢，層層的利潤分攤，zui后，可能出現很多種情況，如：如見不如甲方所愿；服務層層推，一拖再拖；而zui終可以解決問題的設備供貨商或軟件開發商因為各種原因（至少有一個原因是利潤太低）而不情愿及時解決等。
　　
　　以下我們可以具體來分析一卡通系統不宜實施總包的原因：
　　
　　*、一卡通系統不可能出了故障就換
　　
　　包括對講、監控等系統基本上全部由硬件設備組成，設備如果出現問題，工程商可以輕松更換，可以及時響應客戶的各種更新功能需求，可以快速響應服務。但是，一卡通系統與包括：對講、監控有相當大的不同。一卡通系統必然由硬件和軟件組成，硬件設備安裝到位、網絡線路通暢只是*步，接下來包括：如果發卡、卡片后續的有效性管理、卡片的后續備貨是一系列問題；軟件的正確使用、用戶內部具體的操作流程各有不同，如何讓整個系統*適應甲方的實際需求；
　　
　　結果無外乎兩種：要么用戶遷就系統，湊合就用吧；要么就只能換了。
　　
　　第二、一卡通系統前期的建設需要相關部門積極參與，同樣需要軟件開發商的積極參與
　　
　　一卡通系統一般都會涉及單位的后勤、安保、財務、人力資源等多個部門，一卡通系統的建設將直接改變這些部門原來的管理模塊和操作流程。如果沒有這些部門人員的前期參與，只是一味的由基建部門或采購部門人員僅憑文字上承諾的如此這般就確定的話，zui終將很難避免建設的一卡通系統要么不適用，要么根本不能用。
　　
　　另外，這種協調必然需要軟件開發商到現場。我們認為目前幾家較大的智能卡設備廠家提供的一卡通系統雖然功能模塊只限于該公司主力產品，一般都還是包括了：考勤、門禁、消費等，有一些也包括了停車場收費系統。應該說是可以滿足相當一部分客戶的實際需求的。經過雙方有效的溝通，對現有各部門流程進行一定的調整，或者軟件系統再作一定的、較小的調整，是可以達到雙方滿意的。
　　
　　但工程總包方是不可能完成這些工作的，它們甚至根本不愿意提及更詳細的系統功能，只是一味地強調硬件如何的好、廠家的實力如何的強。
　　
　　結果無外乎是談了等于不談，或者等于白談。
　　
　　第三、一卡通系統需要做到“量身訂做”
　　
　　我們認為一卡通系統需要做到量身訂做。道理很簡單，因為當智能卡應用由原來的簡單的吃飯擴展到包括：消費、考勤、門禁、停車、巡更等多個子系統后，就必須涉及單位內部的多個部門；而每個單位內部具體的管理流程都是不相同的，如果拿一套所謂的“大而全”的管理軟件就可以套住所有用戶的需求顯示是不行的。我們在給成都地鐵公司實施就餐管理系統時，我們與甲方就前期的需求及解決方案就討論了半個月，系統建設后他們又試用了一個月才正式啟動；而我們給成都亞東水泥廠建設一卡通系統時就前期需求就溝通了半年。
　　
　　工程總包方為了保證自身的工程利潤，必須壓低系統供應商的價格，能用設備廠商的免費軟件就用，不能用再說。量身訂做是不可能的，甚至在他們看來是不可取的，因為那將導致系統不穩定。我們認為這只是托辭。我們主張量身訂做，不是讓一般軟件公司全新開發，而是讓一卡通系統開發商在原有的成熟系統的基礎上，作適當調整，以期zui終更好的滿足用戶的實際需求，這種修改，經過必要的軟件測試是能夠避免的。套句時髦的話說：“不發展就會落后”。
　　
　　第四、總包方很容易zui終“東拼西湊”
　　
　　事實上，工程商基本止習慣于“東拼西湊”，因為整個弱電項目本來就是多個子系統組成的，我們經常會遇到有工程商十分著急地讓我們給他某個項目安裝一套收費系統，過一段時間又要裝一套巡更系統。這些作為一卡通系統的一個有效組成部分，被他們活生生分成若干部分，今天客戶要求就裝這個，明天客戶要求就裝那個。保證是使用同一張卡就行了。
　　
　　這些子系統從建設到驗收、使用都沒有按“一卡通”的要求來完成，不同的設備再配上一套廠家贈送的管理軟件，在收費系統里發一下，簡單的輸個名字；再到考勤軟件中再輸個相同的名字，再發一次卡，或者想辦法將收費系統的人員信息導到考勤系統中，這樣就可以了。
　　
　　工程驗收時基本上是可以過關的。因為大家都不在乎軟件嘛。但是實際使用起來就有問題了，在消費系統中換了卡，考勤卻打不上；卡找到后又繼續在考勤機上刷卡考勤……凡此種種，zui后可能就是一個人有多張卡，就竟該用哪張卡消費，哪張卡考勤，他自己都弄不清楚。
　　
　　另外，還要說明一點，這些東拼西湊的管理軟件，功能十分的簡單，能用不能用，好用不好用，可能只有zui后具體的操作人員才知道，因為大家都不關心嘛！