實(shí)用的解決方案模板匯總5篇

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

　　解決方案 篇1

　　視頻技術(shù)的發(fā)展正在推動(dòng)以直播為代表的視頻服務(wù)席卷整個(gè)互聯(lián)網(wǎng)，并沖擊著(zhù)傳統行業(yè)，20xx年已然成為了直播元年。同時(shí)，視頻云服務(wù)的元年也悄悄開(kāi)始，不管是互聯(lián)網(wǎng)巨頭還是初創(chuàng )企業(yè)都紛紛進(jìn)軍視頻云行業(yè)。

　　對視頻服務(wù)提供商來(lái)說(shuō)，選擇合適的視頻云服務(wù)對于業(yè)務(wù)的創(chuàng )新和發(fā)展至關(guān)重要。目前市場(chǎng)上的視頻云服務(wù)平臺已經(jīng)多達幾十款，到底哪款才是你的菜呢?小編就市場(chǎng)上聲量比較大的視頻云，從產(chǎn)品功能、穩定性、支持場(chǎng)景和技術(shù)服務(wù)等四個(gè)方面進(jìn)行一個(gè)橫評對比，供你在選擇時(shí)進(jìn)行參考。

　　1、產(chǎn)品功能

　　你一定希望視頻云的功能能夠保證你的視頻服務(wù)順暢運營(yíng)，集成方便，能夠快速上線(xiàn)，并且運維簡(jiǎn)單。但首先需要明確，視頻云服務(wù)包含當前最火熱的直播和相對傳統的點(diǎn)播服務(wù)。除了行業(yè)特性，除了分發(fā)、安全等基礎功能之外，直播和點(diǎn)播需要的高級功能以及技術(shù)實(shí)現還是有很大差別的�？傮w說(shuō)來(lái)，直播技術(shù)難度比點(diǎn)播更大，但不代表直播好的點(diǎn)播就一定好，因此需要根據視頻業(yè)務(wù)的實(shí)際需求和自身技術(shù)實(shí)力進(jìn)行決策。

　　不難發(fā)現，各個(gè)視頻云產(chǎn)品在核心功能上大同小異，但因為分別和各自平臺不同的云服務(wù)矩陣結合，這使得他們有著(zhù)各自的特點(diǎn)。

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

　　七牛直播云：沿襲七牛云的精品路線(xiàn)，側重于直播，開(kāi)放云端 API 實(shí)現透明播控管理，同時(shí)CDN節點(diǎn)相對要少一些。

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

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

　　2、穩定性

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

　　從一定程度上說(shuō)，自建機房意味著(zhù)具備專(zhuān)業(yè)的運維團隊、更強的突發(fā)事件應對能力、更高效的突發(fā)事件響應速度，而這些因素恰恰是提供穩定服務(wù)的關(guān)鍵。此外，傳輸機制保證了數據的安全性，網(wǎng)絡(luò )QoS策略則能夠保障復雜網(wǎng)絡(luò )下的流暢直播體驗。而服務(wù)模式?jīng)Q定了是否能夠快速響應客戶(hù)的技術(shù)、服務(wù)訴求。

　　3、支持場(chǎng)景

　　就前面的分析來(lái)看，不管是在產(chǎn)品功能還是穩定性方面，各個(gè)平臺并未真正的拉開(kāi)差距�；鼐彤斍暗闹辈ナ袌�(chǎng)現狀而言，秀場(chǎng)和游戲直播平臺占據了很大的比重，雖然直播的垂直化和差異化發(fā)展屢被提及，可“直播+”的布道似乎并沒(méi)有想象中那么順利。站在視頻云平臺的角度，大眾市場(chǎng)往往會(huì )淘汰的只剩下幾個(gè)玩家，能否支持更多的場(chǎng)景需要越發(fā)顯得重要。而這些視頻云平臺在場(chǎng)景支持方面表現的怎么樣呢?

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

　　4、技術(shù)服務(wù)

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

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

　　結語(yǔ)

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

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

　　解決方案 篇2

　　Android設置鬧鐘并不像IOS那樣這么簡(jiǎn)單，做過(guò)Android設置鬧鐘的開(kāi)發(fā)者都知道里面的坑有多深。下面記錄一下，我解決Android鬧鐘設置的解決方案。

　　主要問(wèn)題

　　1、API19開(kāi)始AlarmManager的機制修改。

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

　　3、6.0以上進(jìn)入Doze模式會(huì )使JobScheduler停止工作。

　　4、手機設置重啟后，鬧鐘失效問(wèn)題。

　　API19以上AlarmManager機制的修改

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

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

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

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

　　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);}

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

　　應用程序被Kill掉時(shí)的處理

　　應用程序被Kill掉后，設置的鬧鐘失效，這里利用守護進(jìn)程以及灰色�；顏�(lái)保證后臺鬧鐘服務(wù)不被Kill掉。當應用程序以及鬧鐘服務(wù)被Kill掉，守護進(jìn)程以及灰色�；顏�(lái)重新啟動(dòng)鬧鐘服務(wù)，并且重新設置鬧鐘。

　　關(guān)于守護進(jìn)程的處理，這里采用開(kāi)源的守護進(jìn)程庫。Android-AppDaemon

　　在鬧鐘服務(wù)的onCreat加入Android-AppDaemon這個(gè)開(kāi)源的守護進(jìn)程。代碼如下：

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

　　為進(jìn)一步保證鬧鐘服務(wù)的存活，同加上灰色�；睿ɡ�用系統的漏洞啟動(dòng)前臺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()); } //發(fā)送喚醒廣播來(lái)促使掛掉的UI進(jìn)程重新啟動(dòng)起來(lái) 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(); }}

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

　　5.0以上的JobScheduler

　　在這里利用5.0以上的JobScheduler創(chuàng )建一個(gè)定時(shí)的任務(wù)，定時(shí)檢測鬧鐘服務(wù)是否存在，沒(méi)在存在則重新啟動(dòng)鬧鐘服務(wù)。（這里我設置每一分鐘檢測一次鬧鐘服務(wù)）

　　在進(jìn)入應用程序的時(shí)候檢測當前系統是否是5.0以上，如果是則啟動(dòng)JobScheduler這個(gè)服務(wù)。代碼如下：

　　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); //設置設備重啟后，是否重新執行任務(wù) builder.setRequiresDeviceIdle(true); if (mJobScheduler.schedule(builder.build()) <= 0) { //If something goes wrong }}

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

　　上面的操作進(jìn)一步保證了鬧鐘服務(wù)被Kill掉后，重新啟動(dòng)服務(wù)。但是在6.0以上引入了Doze模式，當6.0以上的手機進(jìn)入這個(gè)模式后，便會(huì )使JobScheduler停止工作。

　　6.0以上Doze模式的處理

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

　　在Manifest.xml中加入權限。

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

　　@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; }}

　　如果沒(méi)有忽略電池優(yōu)化的時(shí)候，彈出提醒對話(huà)框，提示用戶(hù)進(jìn)行忽略電池優(yōu)化操作。代碼如下：

　　/*** 針對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(); } }}

　　在界面重寫(xiě)onActivityResult方法來(lái)捕獲用戶(hù)的'選擇。如，代碼如下：

　　@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(), "請開(kāi)啟忽略電池優(yōu)化~"); } }}

　　補充

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

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

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

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

　　@Overrideprotected void onDestroy() { super.onDestroy(); try {//判斷是否有鬧鐘，沒(méi)有則關(guān)閉鬧鐘服務(wù) 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); //解除綁定服務(wù)。 } catch (Exception e) { }}

　　這里說(shuō)明一下，當服務(wù)啟動(dòng)并且被綁定的情況下，unbindService是不會(huì )停止服務(wù)的。

　　最后

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

　　以上就是本文的全部?jì)热�，希望對大家的學(xué)習有所幫助，也希望大家多多支持教程網(wǎng)。

　　解決方案 篇3

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

　　一、調査對象

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

　　二、調査方法

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

　　2.個(gè)別訪(fǎng)談法：調査過(guò)程中，從淮安市范集中學(xué)教師中隨機抽取了個(gè)別任課老師進(jìn)行面對面的訪(fǎng)談，了解存在的問(wèn)題。

　　三、調査內容

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

　　四、調査結果

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

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

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

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

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

　　五、問(wèn)題解決對策的建議

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

　　2.落實(shí)權利義務(wù)關(guān)系。沒(méi)有無(wú)權利的義務(wù)，也沒(méi)有無(wú)義務(wù)的權利，權利和義務(wù)的統一有兩種含義，一是法律關(guān)系一方面權利和義務(wù)的統一：二是法律關(guān)系雙方權利和義務(wù)的統一。權利和義務(wù)不是絕對的，有時(shí)權利也是義務(wù)，在不同場(chǎng)合下，教師的權利和義務(wù)是互相交叉的`，并可以相互轉。

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

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

　　5.建立公平競爭機制?可借鑒西方發(fā)達國家的先進(jìn)管理經(jīng)驗，遵循民主、公正的原則，教師是學(xué)校教學(xué)的主體，學(xué)校應該實(shí)施“教授治�！�，教師應該有充分的權力管理學(xué)校事務(wù)，競爭機制不應該是體現某些領(lǐng)導的意志，而應該讓廣大教師們來(lái)制定大家公認的競爭機制。

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

　　解決方案 篇4

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

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

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

　　CRM升級：最有效的途徑

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

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

　　正如俗話(huà)所說(shuō)的那樣“躲得過(guò)初一，躲不過(guò)十五”�，F在決定實(shí)施系統升級的用戶(hù)只需為升級支付費用。然而，那些推遲其升級計劃的用戶(hù)，將面臨產(chǎn)品不受技術(shù)支持，版本不再適用于企業(yè)需求的諸多風(fēng)險。同時(shí)，他們還可能支付更多的維護費用。當然，還是有一些選擇可供考慮，如：選擇其他的應用供應商。

　　CRM部署：對CRM業(yè)務(wù)進(jìn)行綜合管理

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

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

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

　　新技術(shù)的發(fā)展以及他們對CRM的影響

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

　　·門(mén)戶(hù)（Portal）：盡管門(mén)戶(hù)不是一個(gè)新市場(chǎng)，但是他們正越來(lái)越密切的與CRM業(yè)務(wù)相聯(lián)系。一個(gè)門(mén)戶(hù)機制是集合應用、內容、商業(yè)邏輯或規則、數據以及統一標準的用戶(hù)界面。在為終端用戶(hù)特定業(yè)務(wù)流程的相關(guān)經(jīng)驗提供內容交付時(shí)，門(mén)戶(hù)框架能夠針對特定的終端用戶(hù)、任務(wù)、或職能，實(shí)現其個(gè)性化信息的交付。

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

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

　　如果缺乏合理的CRM技術(shù)計劃，可能導致CRM長(cháng)期計劃混亂無(wú)序。企業(yè)計劃對CRM系統進(jìn)行升級前，應該對其部署選擇進(jìn)行認真評估；同時(shí)，需要對可能成為CRM關(guān)鍵技術(shù)的新興綜合技術(shù)有所了解和認識。

　　解決方案 篇5

　　一、客戶(hù)需求

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

　　1）有一棟教學(xué)樓，3層，每層有教室6間，每間60平米，午睡室6間，每間60平米，每層樓道長(cháng)60米。

　　2）教學(xué)樓入口兩側各有一個(gè)2米寬30米長(cháng)的綠化帶，綠化帶前有一個(gè)500平方米小廣場(chǎng)。

　　3）教學(xué)樓的西側有一棟辦公樓2層，樓道長(cháng)40米。

　　4）辦公樓前有一個(gè)200平方米兒童游樂(lè )場(chǎng)。

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

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

　　1、每天早上，在孩子入園時(shí)間內自動(dòng)播放幼兒歌曲、音樂(lè )、致歡迎詞和問(wèn)候語(yǔ)，下午放學(xué)時(shí)，自動(dòng)播出歡樂(lè )的兒童音樂(lè )歡送小朋友回家，并叮囑注意事項等。

　　2、幼兒園上下課時(shí)使用歡快的音樂(lè )作為上下課鈴聲。

　　3、幼兒午睡開(kāi)始時(shí)播放一些輕柔的搖籃曲，午睡結束時(shí)用音樂(lè )將小朋友喚醒。

　　4、定時(shí)播放少兒廣播體操、眼保健操等音樂(lè )。

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

　　6、臨時(shí)的廣播如：通知、園長(cháng)統一講話(huà)、宣傳表?yè)P先進(jìn)等可以隨時(shí)切換到手動(dòng)控制。

　　二、需求分析及方案設計

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

　　2.對系統進(jìn)行分區廣播，根據幼兒園的具體布局，我們將幼兒園廣播系統分為5個(gè)區，教室分一個(gè)區，午睡室一個(gè)區，辦公樓、教學(xué)樓樓道一個(gè)區，操場(chǎng)、游樂(lè )場(chǎng)一個(gè)區。以滿(mǎn)足幼兒園對廣播不同區域的不同需要。

　　3. 每個(gè)教室和午睡室各安裝一個(gè)6W音箱，為方便各班的幼教老師可及時(shí)的調節廣播音量，我們在每個(gè)音箱前加一個(gè)音量調節開(kāi)關(guān)。

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

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

　　6. 根據功放設計原則我們?yōu)橛變簣@設計2臺合并式功率放大器，一臺350W用于教室和午睡室和樓道，一臺250W用于廣場(chǎng)和游樂(lè )場(chǎng)。

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

　　8. 系統管理員可隨時(shí)結束自動(dòng)播出狀態(tài)，進(jìn)入手動(dòng)狀態(tài)，播放通知，找人，或進(jìn)行緊急廣播等。

　　三、系統主要功能

　　自動(dòng)播放功能——系統可按幼兒園設置的播放時(shí)間表，通過(guò)自動(dòng)播放軟件，全自動(dòng)播背景音樂(lè )、入園音樂(lè )、溫馨的問(wèn)候、祝福語(yǔ)、少兒上下課音樂(lè )鈴聲等。

　　預排播放課表——根據幼兒園安排和管理的需要，系統可預排一天和一周播放課表，每天的播放表可任意設定，不受時(shí)段和時(shí)間長(cháng)短的限制，一周的播放表編排好后，每天計算機開(kāi)機后，系統將自動(dòng)判斷星期幾，然后按照排好的播放表自動(dòng)播放�？纱鎯�、修改、編輯播放表。

　　周循環(huán)功能-——編排好一周的播放時(shí)間表后，全年可循環(huán)播放，而無(wú)需每周重設。

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

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

　　播放臨時(shí)廣播—幼兒園若有臨時(shí)要播放的廣播內容，可隨時(shí)結束自動(dòng)播放狀態(tài)，進(jìn)入手動(dòng)播放狀行播放。

　　無(wú)人值守——廣播控制主機可實(shí)現自動(dòng)開(kāi)關(guān)機，每天開(kāi)機后自動(dòng)識別星期幾，調用當天的播放表自動(dòng)播放，實(shí)現無(wú)人值守。

　　分區功能——可實(shí)現分區自動(dòng)廣播功能。如對幼兒園游樂(lè )場(chǎng)所進(jìn)行音樂(lè )播放，對運動(dòng)場(chǎng)播放幼兒廣播體操等。

　　四、系統設備清單

　　項目

　　規格

　　數量

　　主控制系統

　　GMTD-GBS廣播播放控制主機，自動(dòng)播放軟件，控制軟件

　　1

　　分區控制器

　　GMTD-8DV（8路）

　　1

　　音頻分配器

　　四分十六

　　1

　　合并式功放

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

　　合并式功放

　　GM-8260A（260W）用于廣場(chǎng)和游樂(lè )場(chǎng)

　　1

　　會(huì )議話(huà)筒

　　BK-240

　　2

　　無(wú)線(xiàn)話(huà)筒

　　VAM-2211

　　1

　　壁掛式音箱

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

　　46

　　草坪音箱

　　GM860-1(15W)蘑菇

　　2

　　草坪音箱

　　GM860-15（15W）動(dòng)物

　　1

　　草坪音箱

　　GM860-14（15W）竹型

　　1

　　草坪音箱

　　GM860-09（15W）巖石

　　1

　　草坪音箱

　　GM860-17（15W）巖石

　　1

　　線(xiàn)纜線(xiàn)材

　　網(wǎng)絡(luò )線(xiàn)纜、電源線(xiàn)、射頻線(xiàn)纜、接插件等

　　五、系統拓撲圖

【解決方案】相關(guān)文章：

解決方案05-20

解決方案（實(shí)用）05-27

解決方案優(yōu)秀05-12

行業(yè)解決方案08-16

erp解決方案04-22

oa解決方案05-31

產(chǎn)品解決方案11-19

招聘解決方案02-14

解決方案（精）05-23

解決方案【優(yōu)秀】08-25