實用的解決方案模板匯總5篇

　　為了確定工作或事情順利開展，常常需要提前制定一份優秀的方案，方案是綜合考量事情或問題相關的因素后所制定的書面計劃。優秀的方案都具備一些什么特點呢？下面是小編精心整理的解決方案5篇，僅供參考，歡迎大家閱讀。

　　解決方案 篇1

　　視頻技術的發展正在推動以直播為代表的視頻服務席卷整個互聯網，并沖擊著傳統行業，20xx年已然成為了直播元年。同時，視頻云服務的元年也悄悄開始，不管是互聯網巨頭還是初創企業都紛紛進軍視頻云行業。

　　對視頻服務提供商來說，選擇合適的視頻云服務對于業務的創新和發展至關重要。目前市場上的視頻云服務平臺已經多達幾十款，到底哪款才是你的菜呢?小編就市場上聲量比較大的視頻云，從產品功能、穩定性、支持場景和技術服務等四個方面進行一個橫評對比，供你在選擇時進行參考。

　　1、產品功能

　　你一定希望視頻云的功能能夠保證你的視頻服務順暢運營，集成方便，能夠快速上線，并且運維簡單。但首先需要明確，視頻云服務包含當前最火熱的直播和相對傳統的點播服務。除了行業特性，除了分發、安全等基礎功能之外，直播和點播需要的高級功能以及技術實現還是有很大差別的。總體說來，直播技術難度比點播更大，但不代表直播好的點播就一定好，因此需要根據視頻業務的實際需求和自身技術實力進行決策。

　　不難發現，各個視頻云產品在核心功能上大同小異，但因為分別和各自平臺不同的云服務矩陣結合，這使得他們有著各自的特點。

　　騰訊云視頻：互動直播方案比較成熟，與騰訊云通信(IM)結合緊密，業務集成度較高。

　　七牛直播云：沿襲七牛云的精品路線，側重于直播，開放云端 API 實現透明播控管理，同時CDN節點相對要少一些。

　　金山視頻云：點播數據挖掘、H.265編碼其特色(當然H.265需要視頻源高清而且終端性能強勁才有明顯效果)，客戶端SDK集中在移動端，不過直播還支持OTT播放盒、超級電視等多屏播放。

　　網易視頻云：功能相對完善，同時支持實時互動直播，而且具有各種場景的完整解決方案，擁有千萬級并發量，SDK也非常全面。好吧，其實網易視頻云的最大優勢，就是接入方便，新手也只需一天就可以為APP接入音視頻功能。

　　2、穩定性

　　最近一段時間，云計算的宕機現象再次發生，云服務的穩定性變成了影響用戶抉擇的重要因素之一。當然，對于視頻云服務來說，穩定性不止于數據中心層，更需要考慮視頻流鏈路的穩定，包括對弱網環境的處理，對卡頓、延遲現象有極地的容忍度。那么，今天橫評的四款服務在硬件條件和軟實力方面的表現怎么樣呢?

　　從一定程度上說，自建機房意味著具備專業的運維團隊、更強的突發事件應對能力、更高效的突發事件響應速度，而這些因素恰恰是提供穩定服務的關鍵。此外，傳輸機制保證了數據的安全性，網絡QoS策略則能夠保障復雜網絡下的流暢直播體驗。而服務模式決定了是否能夠快速響應客戶的技術、服務訴求。

　　3、支持場景

　　就前面的分析來看，不管是在產品功能還是穩定性方面，各個平臺并未真正的拉開差距。回就當前的直播市場現狀而言，秀場和游戲直播平臺占據了很大的比重，雖然直播的垂直化和差異化發展屢被提及，可“直播+”的布道似乎并沒有想象中那么順利。站在視頻云平臺的角度，大眾市場往往會淘汰的只剩下幾個玩家，能否支持更多的場景需要越發顯得重要。而這些視頻云平臺在場景支持方面表現的怎么樣呢?

　　對比來看，網易視頻云和騰訊直播云作為有巨頭背景的產品，基于開展本公司視頻業務的技術積累研發，在綜合實力上更有優勢，比如說網易視頻云針對在線教育場景的解決方案已經在網易云課堂、中國大學MOOC等行業知名產品上得到驗證，比較具有說服力。七牛云作為創業公司，雖然只做直播，但涵蓋的場景十分豐富，至少滿足了獵奇的需要。而金山云擁有今日頭條等明星級用戶，但在場景案例上并沒有公布太多，在垂直領域的話語權還亟待考證。

　　4、技術服務

　　企業級云服務和消費級產品最大的.不同，就是對技術服務的需求更甚于對資費的敏感，剛剛發展起來的云服務尤其如此。對于視頻云服務，因為復雜的場景、冗長的鏈路背后是復雜的技術，而視頻服務商還需要快速為自己的用戶解決問題，讓這些最終用戶滿意，所以技術支持必不可少。

　　以上表格中，技術服務的對比一目了然，就無需多說了。需要注意，扁平化的1對1溝通相比走工單的服務形式更加便捷，也可能還更加實惠。

　　結語

　　以上是四款視頻云服務產品在四個層面的比較。另外對價格敏感的擁護，還需要注意服務打包和計費方式，比如美顏、轉碼、鑒黃功能是不是另外收費，CDN是按流量還是按帶寬峰值計費，這里就不細說了。

　　直播創造了無數的網紅，而且直播本身就是互聯網行業中的網紅，這種優越感和吸金能力，讓越來越多的創業者和投資客投入直播的懷抱。正如很多人所說，垂直化和場景化的直播服務將成為未來的主流趨勢，正在孕育著更大的市場，事實上這也是視頻云平臺所希冀的。四款視頻云產品在場景化和直播功能上都有著不錯的表現，網易和騰訊再次承擔了市場領軍者的角色，而金山和七牛在市場上的影響力也越來越大。說到這里，相信對直播感興趣的朋友已經有了自己的選擇。

　　解決方案 篇2

　　Android設置鬧鐘并不像IOS那樣這么簡單，做過Android設置鬧鐘的開發者都知道里面的坑有多深。下面記錄一下，我解決Android鬧鐘設置的解決方案。

　　主要問題

　　1、API19開始AlarmManager的機制修改。

　　2、應用程序被Kill掉后,設置的鬧鐘不響。

　　3、6.0以上進入Doze模式會使JobScheduler停止工作。

　　4、手機設置重啟后，鬧鐘失效問題。

　　API19以上AlarmManager機制的修改

　　API19之前AlarmManager提供了三個設置鬧鐘的方法，由于業務需求鬧鐘只需要一次性，所以采用set(int type，long startTime，PendingIntent pi)；這個方法。

　　從API 19開始，AlarmManager的機制都是非準確傳遞，操作系統將會轉換鬧鐘，來最小化喚醒和電池使用。

　　由于之前的程序，沒有對API19以上的鬧鐘設置做處理，導致在4.4以上的手機設置鬧鐘無響應（應用程序沒有被殺死的情況也沒有鬧鐘）。

　　因些，設置鬧鐘需要根據API的版本進行分別處理設置。代碼如下：

　　AlarmManager am = (AlarmManager) getActivity() .getSystemService(Context.ALARM_SERVICE);if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { am.setExact(AlarmManager.RTC_WAKEUP, TimeUtils .stringToLong(recordTime, TimeUtils.NO_SECOND_FORMAT), sender);}else { am.set(AlarmManager.RTC_WAKEUP, TimeUtils .stringToLong(recordTime, TimeUtils.NO_SECOND_FORMAT), sender);}

　　這樣，保證鬧鐘在應用程序沒有被Kill掉的情況鬧鐘。

　　應用程序被Kill掉時的處理

　　應用程序被Kill掉后，設置的鬧鐘失效，這里利用守護進程以及灰色保活來保證后臺鬧鐘服務不被Kill掉。當應用程序以及鬧鐘服務被Kill掉，守護進程以及灰色保活來重新啟動鬧鐘服務，并且重新設置鬧鐘。

　　關于守護進程的處理，這里采用開源的守護進程庫。Android-AppDaemon

　　在鬧鐘服務的onCreat加入Android-AppDaemon這個開源的守護進程。代碼如下：

　　@Overridepublic void onCreate() { super.onCreate(); Daemon.run(DaemonService.this, DaemonService.class, Daemon.INTERVAL_ONE_MINUTE); startTimeTask(); grayGuard();}

　　為進一步保證鬧鐘服務的存活，同加上灰色保活（利用系統的漏洞啟動前臺Service）。

　　代碼如下：

　　private void grayGuard() { if (Build.VERSION.SDK_INT < 18) { //API < 18 ，此方法能有效隱藏Notification上的圖標 startForeground(GRAY_SERVICE_ID, new Notification()); } else { Intent innerIntent = new Intent(this, DaemonInnerService.class); startService(innerIntent); startForeground(GRAY_SERVICE_ID, new Notification()); } //發送喚醒廣播來促使掛掉的UI進程重新啟動起來 AlarmManager alarmManager = (AlarmManager) getSystemService(Context.ALARM_SERVICE); Intent alarmIntent = new Intent(); alarmIntent.setAction(WakeReceiver.GRAY_WAKE_ACTION); PendingIntent operation = PendingIntent.getBroadcast(this, WAKE_REQUEST_CODE, alarmIntent, PendingIntent.FLAG_UPDATE_CURRENT); if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { alarmManager.setWindow(AlarmManager.RTC_WAKEUP, System.currentTimeMillis(), ALARM_INTERVAL, operation); }else { alarmManager.setInexactRepeating(AlarmManager.RTC_WAKEUP, System.currentTimeMillis(), ALARM_INTERVAL, operation); }}/** * 給 API >= 18 的平臺上用的灰色保活手段 */public static class DaemonInnerService extends Service { @Override public void onCreate() { Log.i(LOG_TAG, "InnerService -> onCreate"); super.onCreate(); } @Override public int onStartCommand(Intent intent, int flags, int startId) { Log.i(LOG_TAG, "InnerService -> onStartCommand"); startForeground(GRAY_SERVICE_ID, new Notification()); //stopForeground(true); stopSelf(); return super.onStartCommand(intent, flags, startId); } @Override public IBinder onBind(Intent intent) { throw new UnsupportedOperationException("Not yet implemented"); } @Override public void onDestroy() { Log.i(LOG_TAG, "InnerService -> onDestroy"); super.onDestroy(); }}

　　上面操作盡可能提高鬧鐘服務的存活。但是在5.0以上的手機，利用系統的自帶的Clean功能的時候，還是會將鬧鐘服務徹底的干掉。為了解決5.0以上的問題，這里引入5.0以上的新特性 JobScheduler。

　　5.0以上的JobScheduler

　　在這里利用5.0以上的JobScheduler創建一個定時的任務，定時檢測鬧鐘服務是否存在，沒在存在則重新啟動鬧鐘服務。（這里我設置每一分鐘檢測一次鬧鐘服務）

　　在進入應用程序的時候檢測當前系統是否是5.0以上，如果是則啟動JobScheduler這個服務。代碼如下：

　　if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { mJobScheduler = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE); JobInfo.Builder builder = new JobInfo.Builder(JOB_ID, new ComponentName(getPackageName(), JobSchedulerService.class.getName())); builder.setPeriodic(60 * 1000); //每隔60秒運行一次 builder.setRequiresCharging(true); builder.setPersisted(true); //設置設備重啟后，是否重新執行任務 builder.setRequiresDeviceIdle(true); if (mJobScheduler.schedule(builder.build()) <= 0) { //If something goes wrong }}

　　其中的builder.setPersisted(true); 方法是設備重啟后，是否重新執行任務，在這測過是可以重新啟動任務的。

　　上面的操作進一步保證了鬧鐘服務被Kill掉后，重新啟動服務。但是在6.0以上引入了Doze模式，當6.0以上的手機進入這個模式后，便會使JobScheduler停止工作。

　　6.0以上Doze模式的處理

　　為了讓JobScheduler可以在6.0以上進入Doze模式工作，這里針對6.0以上的Doze模式做特殊的處理-忽略電池的優化。

　　在Manifest.xml中加入權限。

　　在設置鬧鐘的時候，判斷系統是否是6.0以上，如果是,則判斷是否忽略電池的優化。判斷是否忽略電池優化代碼如下：

　　@TargetApi(Build.VERSION_CODES.M)public static boolean isIgnoringBatteryOptimizations(Activity activity){ String packageName = activity.getPackageName(); PowerManager pm = (PowerManager) activity .getSystemService(Context.POWER_SERVICE); if (pm.isIgnoringBatteryOptimizations(packageName)) { return true; }else { return false; }}

　　如果沒有忽略電池優化的時候，彈出提醒對話框，提示用戶進行忽略電池優化操作。代碼如下：

　　/*** 針對N以上的Doze模式** @param activity*/public static void isIgnoreBatteryOption(Activity activity) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { try { Intent intent = new Intent(); String packageName = activity.getPackageName(); PowerManager pm = (PowerManager) activity.getSystemService(Context.POWER_SERVICE); if (!pm.isIgnoringBatteryOptimizations(packageName)) {// intent.setAction(Settings.ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS); intent.setAction(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS); intent.setData(Uri.parse("package:" + packageName)); activity.startActivityForResult(intent, REQUEST_IGNORE_BATTERY_CODE); } } catch (Exception e) { e.printStackTrace(); } }}

　　在界面重寫onActivityResult方法來捕獲用戶的'選擇。如，代碼如下：

　　@Overrideprotected void onActivityResult(int requestCode, int resultCode, Intent data) { if (resultCode == RESULT_OK) { if (requestCode == BatteryUtils.REQUEST_IGNORE_BATTERY_CODE){ //TODO something } }else if (resultCode == RESULT_CANCELED){ if (requestCode == BatteryUtils.REQUEST_IGNORE_BATTERY_CODE){ ToastUtils.show(getActivity(), "請開啟忽略電池優化~"); } }}

　　補充

　　當應用程序被Kill掉，但是鬧鐘的服務沒有被Kill掉的，這時候又設置了鬧鐘。這就意味著設置的鬧鐘沒有放到鬧鐘服務那里。所以這種情況，設置的鬧鐘會失效。為了解決這種情況，利用AIDL（鬧鐘服務在另一個進程的需要進程間通信）調用鬧鐘服務的重新設置鬧鐘方法重設鬧鐘。

　　在應用程序的onCreat()方法啟動鬧鐘服務，然后再綁定鬧鐘服務。

　　private void initAlarmService() { startService(new Intent(this, DaemonService.class));//啟動鬧鐘服務 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { //JobScheduler ... } //綁定鬧鐘服務 Intent intent = new Intent(this, DaemonService.class); intent.setAction("android.intent.action.DaemonService"); bindService(intent, mConnection, Context.BIND_AUTO_CREATE);}

　　在onDestroy()方法，調用鬧鐘服務的重設鬧鐘方法。代碼如下：

　　@Overrideprotected void onDestroy() { super.onDestroy(); try {//判斷是否有鬧鐘，沒有則關閉鬧鐘服務 String alarm = localPreferencesHelper.getString(LocalPreferencesHelper.ALARM_CLOCK); if (daemonService != -1 && mIRemoteService != null) {// android.os.Process.killProcess(daemonService); mIRemoteService.resetAlarm(); } if (!alarm.equals("[]")) { if (daemonService != -1) { startService(new Intent(this, DaemonService.class)); } } else { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { mJobScheduler.cancel(JOB_ID); } } unbindService(mConnection); //解除綁定服務。 } catch (Exception e) { }}

　　這里說明一下，當服務啟動并且被綁定的情況下，unbindService是不會停止服務的。

　　最后

　　以上并不代表所有的Android手機的鬧鐘都可以用，這只是盡最大的可能保證大部分的手機。

　　以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持教程網。

　　解決方案 篇3

　　教師的業務素質、思想道德水平、身體健康狀況，將直接影響教學效果和教育成敗，將間接影響到民族的興衰。當前我們國家教育處在相對好的發展態勢，在現代化建設新常態下教育一線成績不容否定，但問題也很普遍，為査找問題、尋求對策，展開了調査研究。

　　一、調査對象

　　選擇江蘇省淮安市范集中學全體教師進行調査，基本能代表當前高中教育管理的現狀。

　　二、調査方法

　　1.問卷調査法：本次問卷全部自編，運用系統抽樣方法，向淮安市范集中學教師發出45份，收回45份，全部有效。

　　2.個別訪談法：調査過程中，從淮安市范集中學教師中隨機抽取了個別任課老師進行面對面的訪談，了解存在的問題。

　　三、調査內容

　　在參考文獻的基礎上，編制調査問卷和訪談提綱。當前高中教育管理過程中存在什么樣問題，具體表現在什么地方，受調査或受訪個體對此有什么想法？

　　四、調査結果

　　1.付出與回報不對等。長期以來，對教師道德水平的要求過度強調了奉獻，常以圣賢的標準要求教師，要求教師照亮別人燃燒自己。如果教師提出條件或待遇時，則被認為是師德不高，為領導和社會所鄙視。教師的勞動(包括顯性和隱性的、直接或間接的、校內或校外的)常常被人忽視，甚至被所教學生忽視，很難獲得相應的政治經濟待遇。當教師全身心投入工作后，但其勞動被無償占有或者不被他人認可，不能贏得社會尊重，不能滿足自己求生存求發展的愿望。

　　2.權利與義務不均衡。雖然有《教師法》、《教育法》等法律保障教師權益，但實際上教師權益并未真正得到落實。學校定罱和定性考核手法多樣，無論怎么制定，都突出領導如何對教師進行管控，視教師為可操控的機器人，基本未考慮教師工作中如何行使權力，如何發揮主觀主動。

　　3.工作負荷超標準。教師普遍超負荷工作。按人社部規定的“標準”，職工月平均工作天數為20.92天，時間為167.4小時。高中教師月工作26—28天，平均每天工作12—15小時，遠超國家標準。大部分教師長年累月重復著每天“早六晚十”披星戴月的工作節律和“辦公室一地一食堂”三點一線的生活軌跡，簡單而枯燥。

　　4.評價制度與實際脫節。教學評價本該全面、客觀、公平、公正，做到統一性和多樣性、定量和定性評價相兼顧，而實際運作中，重智輕德，甚至不談德。簡單地把考試成績、升學比例作為評價依據，忽視了學生和教師的個體差異性、多樣性、復雜性。特別是行政干預、領導主觀臆斷、人為的感情好惡等嚴重損害了本該公正的教學評價，出現了鉆營取巧者得利，踏實肯干者吃虧的現象。

　　5.競爭機制不公。由于教師職業性質的特殊性決定，絕大多數教師的政治生命黯淡無光，在晉級和提拔方面機會甚少，成為名師更是奢想，多數教師把眼睛盯在職稱晉升、榮譽授予、獎金發放等方面。實際情況是由于沒有具體明確的細則，留有太大的彈性空間，缺乏公開公正和透明的機制，嚴重地損害了榮譽、職務、職稱的權威。這種現象雖然不普遍，但它對教育人文環境的污染，對教師人格的扭曲不可小視，招致其它社會成員的誤解在所難免。

　　五、問題解決對策的建議

　　1.加大教育投入裂度。教育投入是支撐國家長遠發展的越礎性、戰略性投資，是發展教育事業的重要物質基礎，推動教育優先發展的重要保障，多管齊下促進發展。依法加大教育經費投入，逐步提高財政性教育經費占市內生產總值的比例。同時，拓寬籌資渠道，積極鼓勵企業、社會團體和個人捐助教育，對教師額外的付出給以經濟肯定，提高教師的生活福利待遇，以解決教師收入偏低現狀的問題。

　　2.落實權利義務關系。沒有無權利的義務，也沒有無義務的權利，權利和義務的統一有兩種含義，一是法律關系一方面權利和義務的統一：二是法律關系雙方權利和義務的統一。權利和義務不是絕對的，有時權利也是義務，在不同場合下，教師的權利和義務是互相交叉的`，并可以相互轉。

　　3.減輕教師工作罱。學校要力求科學地設定教師的工作量，為教師工作量設定上限，縮減非必要性的文案工作、正確對待展示性活動、引入適S的隱形教學支架如果教材前后鋪陳效果好，學生也可以自學，減輕教師工作量。

　　4.加強評價制度建設。加強制度建設、細化評審規則、規范運作程序、限制行政權力的過多干預、強化客觀硬件、弱化主觀色彩、加強群眾監督、增加透明度、賦予每個教師申訴和辯解等權力迫在眉睫。

　　5.建立公平競爭機制?可借鑒西方發達國家的先進管理經驗，遵循民主、公正的原則，教師是學校教學的主體，學校應該實施“教授治校”，教師應該有充分的權力管理學校事務，競爭機制不應該是體現某些領導的意志，而應該讓廣大教師們來制定大家公認的競爭機制。

　　教師承擔起教育的重擔，也就肩挑著民族的未來，理應服從教育大局，無私奉獻自己的力量。另一方面每個社會成員特別是教育管理人員也應該切實了解教育現狀，樹立平等意識，強化服務意識，解決實際問題。這樣，教育事業才能如高升之日蓬勃發展。

　　解決方案 篇4

　　根據METATrend的研究：20xx-2005年期間，由于缺乏充分的認識而導致出現的技術過度投資，驅使組織主動地將其CRM計劃與他們的經營策略進行重新整合。同時，由于原先被繼承的應用面臨版本停產（EndOfLife），激發組織對其下一代CRM體系進行升級；到20xx年，CRM改革將成為主流企業的一項戰略性發展趨勢，并得到行業定制（industry-specific）產品、面向服務的體系結構、集成框架，以及相應的價值體系的支持。與此同時，Global20xx的CRM系統將有15%臨近結束狀態，并已成功地將用戶產品周期管理滲透到他們的商業過程中。

　　7年前，單塊集成電路的兩層客戶/服務器應用（two-tierclient/server）是當時的標準規范；目前，面向Web的、多層（n-tier）體系結構已經變得普通。隨著大多數供應商已逐步形成面向服務的體系結構，促使整個行業普遍置身于新的進化發展階段。對于從事CRM的企業來說，這次體系結構的進化發展將直接影響其CRM升級。

　　圍繞CRM的部署方法一直存在許多言過其實的宣傳。爭論的焦點集中于究竟是內建（on-premises），還是采用租用方式（hostedCRM）？從根本上來說，無論何種類型或規模的企業都希望了解hostedCRM的解決方案是否適用于自己的組織。此外，大量新興技術開始對CRM技術產生直接影響，包括：門戶技術（portal）、業務流程管理（BPM）、以及客戶數據集成（CDI，CustomerDataIntegration）等等。一旦技術領域的工作趨于成熟，同時企業也將不遺余力地將其更多的努力集中于跨功能和跨系統集成方面，可以預見，創新的解決方案勢必在CRM策略中被探索發現。

　　CRM升級：最有效的途徑

　　20xx年將拋起一場CRM升級的潮流，這對于CRM供應商和系統集成商來說無疑是個好消息，同時也受到用戶的期待。驅使CRM升級的主要因素有兩個：首先，針對大多數供應商產品被抑制的需求最近得到釋放，這被描述為體系結構設計的一次巨大突破。20xx-2003年期間，由于IT資源限制的原因，大多數用戶不得不推遲他們的升級計劃。事實上，對下一代體系結構進行升級可能會面臨更多的困難，并且可實現的投資回報也將低于預期希望。然而，隨著大多數供應商第一代Web體系結構第二或第三版本的發布，用戶購買力的增強，以及用戶意識到他們的許多版本已不再適用（或者處于不好的狀態）等因素的影響，將促使用戶考慮在今年內對CRM系統進行升級，或者至少促使他們計劃在未來12個內進行系統升級。

　　驅使CRM升級的第二個主要因素是由于存在一些難以處理問題。除了用戶承諾不進行升級，一些供應商（如：Siebel）計劃在今年為其客戶或舊版本實施顯著的增強型維護。另外一些供應商則針對舊版本系統，采用減少技術支持人員的'方式，或完全取消相應的技術支持。

　　正如俗話所說的那樣“躲得過初一，躲不過十五”。現在決定實施系統升級的用戶只需為升級支付費用。然而，那些推遲其升級計劃的用戶，將面臨產品不受技術支持，版本不再適用于企業需求的諸多風險。同時，他們還可能支付更多的維護費用。當然，還是有一些選擇可供考慮，如：選擇其他的應用供應商。

　　CRM部署：對CRM業務進行綜合管理

　　例如應用的最佳配合、發展和遷移、IT成熟、IT限制條件、以及所有權成本等關鍵性問題，必須在制訂CRM部署決定之前得到慎重考慮。無論是hostedCRM應用或是on-premisesCRM應用，都能為企業提供顯著的價值交付（盡管企業并不需要過多的考慮交付模型）。進一步說，當涉及到IT限制和商業限制問題時，調整好的CRM應用將更加有效地支持現在以及將來的業務和技術要求。從而促使CRM計劃的成功取得最大的可能性。

　　HostedCRM供應商，尤其是salesforce.com，大力宣傳其CRM產品并引起市場的廣泛關注。METAGroup的客戶期望hostedCRM供應商交付的應用能夠滿足他們的企業發展要求；總的來說，采用hostedCRM解決方案的用戶對他們的投資感到滿意。即便他們的投資范圍受到一定程度的局限（如：接觸管理、渠道報告），但hostedCRM解決方案更快捷、更廉價、更佳的功能性，仍然受到大多數企業的青睞。此外，在許多情形中，CRM業務轉換的長期策略開始演變為一種短期策略。解決方案的迅速實施以及價值創造的進程成為用戶關注的焦點。這種策略性轉變是從CRM的早期發展（1997-20xx年期間）中探索而來。

　　企業必須接受的現實是，他們將最終執行on-premises應用，選擇使用hosted解決方案，并且將組織CRM業務的全部功能和系統（如：呼叫中心）承包給專業的outsource呼叫中心。目前來說，由于這個問題還沒有找到最有效的解決途徑，因此無法就所有情形給出一個具體的解決方案。世界經濟新秩序下的部署選擇，其關鍵性問題在于如何對各種類型的CRM業務進行組合和管理，以及如何促使組合業務最終支持企業的CRM策略。

　　新技術的發展以及他們對CRM的影響

　　一體化進程無疑是CRM面臨的最大挑戰并且是最耗費資源的行動。概括而言，公司每年在CRM許可上需要支付1美元，針對CRM許可的咨詢和執行服務則需花費3美元。60%的CRM服務成本花費在系統和數據的集成方面。同時，CRM一體化進程還受到大量工具、方法和技術的直接影響。在此情況下，為滿足綜合解決方案的創新要求，新技術和新市場迅速應運而生。綜上所述，需要對以下技術進行密切關注：

　　·門戶（Portal）：盡管門戶不是一個新市場，但是他們正越來越密切的與CRM業務相聯系。一個門戶機制是集合應用、內容、商業邏輯或規則、數據以及統一標準的用戶界面。在為終端用戶特定業務流程的相關經驗提供內容交付時，門戶框架能夠針對特定的終端用戶、任務、或職能，實現其個性化信息的交付。

　　·業務流程管理（BPM）：很多企業試圖忽視部門的工作流程，直接對整個企業實行業務流程管理。由于目前的業務流程管理還不夠規范，并且相關的解決方案要求大量組件實現集成（例如：建模、規則引擎、協調、集成服務器、監視、最優化，等等），因此BPM的發展目標強調實現業務流程全部功能性的明晰化、自動化、和最優化。對于實施CRM策略的企業來說BPM尤為重要，因為銷售、服務、業務處理等流程不僅與企業內部的諸多職能密切聯系（如：訂單管理、廣告宣傳、生產），同時還將直接影響其外部（如：渠道、合作伙伴）。

　　·客戶數據集成（CDI）：CDI是通過潛在的數據集成、合并、以及互用性，為全面實施用戶操作而設計的一種策略。針對單個或團隊用戶運用價值計量學方法（如：用戶收益率），使客戶關系管理策略得到有效利用和實施，并隨著時間推移不斷得到改進。全面的用戶CDI策略要求對現有的新生價值和未來的CRM投資有具體的認識，并且具備實施和操作的獨特計劃。根本上來說，由于CDI承諾能夠為用戶創建一個貫穿CRM全過程的單一記錄，因此它被視為CRM策略的一個長期努力目標。

　　如果缺乏合理的CRM技術計劃，可能導致CRM長期計劃混亂無序。企業計劃對CRM系統進行升級前，應該對其部署選擇進行認真評估；同時，需要對可能成為CRM關鍵技術的新興綜合技術有所了解和認識。

　　解決方案 篇5

　　一、客戶需求

　　我們是某市的一所幼兒園，現想建設一套智能廣播系統，幼兒園具體建筑結構如下：

　　1）有一棟教學樓，3層，每層有教室6間，每間60平米，午睡室6間，每間60平米，每層樓道長60米。

　　2）教學樓入口兩側各有一個2米寬30米長的綠化帶，綠化帶前有一個500平方米小廣場。

　　3）教學樓的西側有一棟辦公樓2層，樓道長40米。

　　4）辦公樓前有一個200平方米兒童游樂場。

　　5）幼兒園東西兩側圍墻前各有3米的綠化帶。

　　所建智能廣播系統的具體功能要求如下：

　　1、每天早上，在孩子入園時間內自動播放幼兒歌曲、音樂、致歡迎詞和問候語，下午放學時，自動播出歡樂的兒童音樂歡送小朋友回家，并叮囑注意事項等。

　　2、幼兒園上下課時使用歡快的音樂作為上下課鈴聲。

　　3、幼兒午睡開始時播放一些輕柔的搖籃曲，午睡結束時用音樂將小朋友喚醒。

　　4、定時播放少兒廣播體操、眼保健操等音樂。

　　5、在綠化帶內安裝草坪卡通音箱，使之與幼兒園的整體環境統一協調。

　　6、臨時的廣播如：通知、園長統一講話、宣傳表揚先進等可以隨時切換到手動控制。

　　二、需求分析及方案設計

　　1. 幼兒園是一個特殊公共場所，根據少兒天性好動，對新事物感興趣的特點，本廣播系統應當更加具有人性化的成分。根據需求我們需在廣播系統的`前端加上一臺多媒體計算機，并配備自動播出軟件，即可將每天需固定播出的廣播內容，提前排成播放表，到時自動播出，整個系統造價低，實現簡單。

　　2.對系統進行分區廣播，根據幼兒園的具體布局，我們將幼兒園廣播系統分為5個區，教室分一個區，午睡室一個區，辦公樓、教學樓樓道一個區，操場、游樂場一個區。以滿足幼兒園對廣播不同區域的不同需要。

　　3. 每個教室和午睡室各安裝一個6W音箱，為方便各班的幼教老師可及時的調節廣播音量，我們在每個音箱前加一個音量調節開關。

　　4. 根據綠化帶的長度及廣場、游樂場的面積我們在綠化帶內安裝6只30W草坪卡通音箱，以滿足廣場、游樂場的廣播需求。

　　5. 在辦公樓、教學樓的樓道內每層安裝6W壁掛式音箱2只，共10只。

　　6. 根據功放設計原則我們為幼兒園設計2臺合并式功率放大器，一臺350W用于教室和午睡室和樓道，一臺250W用于廣場和游樂場。

　　7. 金邁視訊廣播自動播出軟件中配套有錄音軟件和音頻編輯軟件，幼兒園管理者可利用這些軟件，將少兒自辦的節目編輯成音樂文件，利用廣播系統定時連續播放。

　　8. 系統管理員可隨時結束自動播出狀態，進入手動狀態，播放通知，找人，或進行緊急廣播等。

　　三、系統主要功能

　　自動播放功能——系統可按幼兒園設置的播放時間表，通過自動播放軟件，全自動播背景音樂、入園音樂、溫馨的問候、祝福語、少兒上下課音樂鈴聲等。

　　預排播放課表——根據幼兒園安排和管理的需要，系統可預排一天和一周播放課表，每天的播放表可任意設定，不受時段和時間長短的限制，一周的播放表編排好后，每天計算機開機后，系統將自動判斷星期幾，然后按照排好的播放表自動播放。可存儲、修改、編輯播放表。

　　周循環功能-——編排好一周的播放時間表后，全年可循環播放，而無需每周重設。

　　播放容量大——可把成千上萬的鈴聲音樂，背景音樂，廣告音樂片等等存儲在計算機中，形成有聲文件素材庫，供編排播放表時進行選擇，還可播放光盤上的音頻文件。

　　設定播放標識符——可根據播放內容自行設定各類播放標識符，如上學歡迎曲、家長溫馨提示、上課鈴聲、下課鈴聲、少兒播音等，方便識別播放內容及播放文件的調用。

　　播放臨時廣播—幼兒園若有臨時要播放的廣播內容，可隨時結束自動播放狀態，進入手動播放狀行播放。

　　無人值守——廣播控制主機可實現自動開關機，每天開機后自動識別星期幾，調用當天的播放表自動播放，實現無人值守。

　　分區功能——可實現分區自動廣播功能。如對幼兒園游樂場所進行音樂播放，對運動場播放幼兒廣播體操等。

　　四、系統設備清單

　　項目

　　規格

　　數量

　　主控制系統

　　GMTD-GBS廣播播放控制主機，自動播放軟件，控制軟件

　　1

　　分區控制器

　　GMTD-8DV（8路）

　　1

　　音頻分配器

　　四分十六

　　1

　　合并式功放

　　GM-8360A（360W）用于教室和午睡室和樓道

　　合并式功放

　　GM-8260A（260W）用于廣場和游樂場

　　1

　　會議話筒

　　BK-240

　　2

　　無線話筒

　　VAM-2211

　　1

　　壁掛式音箱

　　GM-356（3W/6W）用于教室

　　46

　　草坪音箱

　　GM860-1(15W)蘑菇

　　2

　　草坪音箱

　　GM860-15（15W）動物

　　1

　　草坪音箱

　　GM860-14（15W）竹型

　　1

　　草坪音箱

　　GM860-09（15W）巖石

　　1

　　草坪音箱

　　GM860-17（15W）巖石

　　1

　　線纜線材

　　網絡線纜、電源線、射頻線纜、接插件等

　　五、系統拓撲圖

【解決方案】相關文章：

解決方案05-20

解決方案（實用）05-27

解決方案優秀05-12

行業解決方案08-16

erp解決方案04-22

oa解決方案05-31

產品解決方案11-19

招聘解決方案02-14

解決方案（精）05-23

解決方案【優秀】08-25